Re: GUC and postgresql.conf docs

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: GUC and postgresql.conf docs
Дата
Msg-id 7932.1052834070@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: GUC and postgresql.conf docs  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: GUC and postgresql.conf docs  (Peter Eisentraut <peter_e@gmx.net>)
Re: GUC and postgresql.conf docs  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> {"server_encoding", PGC_USERSET}, &server_encoding_string,
> "SQL_ASCII", assign_server_encoding, show_server_encoding

> Do we even need this one?  If you want to find out the server encoding
> (which should be rare anyway), you can select it from pg_database.

This is now in the same class as server_version, i.e., it's a read-only
GUC variable.  I did it that way so that these values could be
transmitted to the frontend via the new 3.0 protocol's ParameterStatus
mechanism.

I know we have a difference of opinion about the cleanliness of
read-only "variables", but I think it's a reasonable approach to take.
It certainly beats inventing a mechanism that duplicates the display
portions of GUC.  For instance, isn't "show lc_collate" a lot better
than having to run pg_controldata to find out the database locale?
        regards, tom lane



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

Предыдущее
От: Þórhallur Hálfdánarson
Дата:
Сообщение: Re: Scheduled jobs
Следующее
От: Tom Lane
Дата:
Сообщение: Re: LIKE indexing proposal