aboutsummaryrefslogtreecommitdiff
path: root/src/bin/psql/variables.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2017-02-02 20:16:17 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2017-02-02 20:16:17 -0500
commitfd6cd698031d3dbeccafde49a8b118cb840312aa (patch)
tree725acd993c50c986dc87672e7b4e977deaf38f91 /src/bin/psql/variables.c
parent8ac0365c22f20dcd2a6b6752b95b665ada83e858 (diff)
downloadpostgresql-fd6cd698031d3dbeccafde49a8b118cb840312aa.tar.gz
postgresql-fd6cd698031d3dbeccafde49a8b118cb840312aa.zip
Clean up psql's behavior for a few more control variables.
Modify FETCH_COUNT to always have a defined value, like other control variables, mainly so it will always appear in "\set" output. Add hooks to force HISTSIZE to be defined and require it to have an integer value. (I don't see any point in allowing it to be set to non-integral values.) Add hooks to force IGNOREEOF to be defined and require it to have an integer value. Unlike the other cases, here we're trying to be bug-compatible with a rather bogus externally-defined behavior, so I think we need to continue to allow "\set IGNOREEOF whatever". Fix it so that the substitution hook silently replace non-numeric values with "10", so that the stored value always reflects what we're really doing. Add a dummy assign hook for HISTFILE, just so it's always in variables.c's list. We can't require it to be defined always, because that would break the interaction with the PSQL_HISTORY environment variable, so there isn't any change in visible behavior here. Remove tab-complete.c's private list of known variable names, since that's really a maintenance nuisance. Given the preceding changes, there are no control variables it won't show anyway. This does mean that if for some reason you've unset one of the status variables (DBNAME, HOST, etc), that variable would not appear in tab completion for \set. But I think that's fine, for at least two reasons: we shouldn't be encouraging people to use those variables as regular variables, and if someone does do so anyway, why shouldn't it act just like a regular variable? Remove ugly and no-longer-used-anywhere GetVariableNum(). In general, future additions of integer-valued control variables should follow the paradigm of adding an assign hook using ParseVariableNum(), so there's no reason to expect we'd need this again later. Discussion: https://postgr.es/m/17516.1485973973@sss.pgh.pa.us
Diffstat (limited to 'src/bin/psql/variables.c')
-rw-r--r--src/bin/psql/variables.c25
1 files changed, 0 insertions, 25 deletions
diff --git a/src/bin/psql/variables.c b/src/bin/psql/variables.c
index 9ca100095f6..d9d07631a59 100644
--- a/src/bin/psql/variables.c
+++ b/src/bin/psql/variables.c
@@ -180,31 +180,6 @@ ParseVariableNum(const char *value, const char *name, int *result)
}
/*
- * Read integer value of the numeric variable named "name".
- *
- * Return defaultval if it is not set, or faultval if its value is not a
- * valid integer. (No error message is issued.)
- */
-int
-GetVariableNum(VariableSpace space,
- const char *name,
- int defaultval,
- int faultval)
-{
- const char *val;
- int result;
-
- val = GetVariable(space, name);
- if (!val)
- return defaultval;
-
- if (ParseVariableNum(val, NULL, &result))
- return result;
- else
- return faultval;
-}
-
-/*
* Print values of all variables.
*/
void