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
Re: GUC and postgresql.conf docs |
Список | 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 по дате отправления: