Re: psql --help=variables lists variables that can't be set

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: psql --help=variables lists variables that can't be set
Дата
Msg-id 20151204062345.GP5136@alap3.anarazel.de
обсуждение исходный текст
Ответ на psql --help=variables lists variables that can't be set  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
On 2015-12-03 22:08:31 -0500, Peter Eisentraut wrote:
> psql --help=variables shows variables treated specially by psql.  And it
> tells you
> 
> Usage:
>   psql --set=NAME=VALUE
>   or \set NAME VALUE
> 
> But some of the variables listed cannot usefully be set, only read, such as
> 
>   DBNAME             the currently connected database name
>   HOST               the currently connected database server
>   LASTOID            the value of last affected OID
> 
> These can be read in a script, but there is nothing useful you can do
> with them on the command line.

Well, you can display them, which actually isn't uninteresting (-c
'\echo :DBNAME'), and at least LASTOID is rather interesting for
scripting purposes.

> Also, for variables such as HISTCONTROL, IGNOREEOF, PROMPT*, they are
> more commonly set in psqlrc, not on the command line.
> 
> Should we trim this list down to variables that are actually useful to
> set on the command line?

I think the increased discoverability isn't a bad thing, so I'm inclined
to not do that.

> I also have some concerns about the listed environment variables.  The
> list of libpq PG* variables is incomplete, and if we're going to curate
> the list, we surely don't need to show the "not recommended" PGPASSWORD
> variable.
>
> That list probably also needs some ifdefs, since SHELL and TMPDIR don't
> work on Windows, and PSQL_HISTORY only works when readline support is built.

I don't have much an opinion about those. I think it's not too bad to
show them regardless, nor is it bad to hide them.



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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: pg_hba_lookup function to get all matching pg_hba.conf entries
Следующее
От: Noah Misch
Дата:
Сообщение: Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.