[COMMITTERS] pgsql: Clean up psql's behavior for a few more control variables.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема [COMMITTERS] pgsql: Clean up psql's behavior for a few more control variables.
Дата
Msg-id E1cZSUB-0007kV-UT@gemulon.postgresql.org
обсуждение исходный текст
Список pgsql-committers
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

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/fd6cd698031d3dbeccafde49a8b118cb840312aa

Modified Files
--------------
doc/src/sgml/ref/psql-ref.sgml | 22 ++++--------
src/bin/psql/help.c            |  4 +--
src/bin/psql/input.c           |  5 +--
src/bin/psql/mainloop.c        |  2 +-
src/bin/psql/settings.h        |  2 ++
src/bin/psql/startup.c         | 79 +++++++++++++++++++++++++++++++++++++++---
src/bin/psql/tab-complete.c    | 26 ++------------
src/bin/psql/variables.c       | 25 -------------
src/bin/psql/variables.h       |  5 ---
9 files changed, 90 insertions(+), 80 deletions(-)


В списке pgsql-committers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: [COMMITTERS] pgsql: Avoid improbable null pointer dereference inpgpassfileWarning()
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [COMMITTERS] pgsql: pageinspect: Support hash indexes.