Re: let's make the list of reportable GUCs configurable (was Re: Add %r substitution for psql prompts to show recovery status)
От | Tom Lane |
---|---|
Тема | Re: let's make the list of reportable GUCs configurable (was Re: Add %r substitution for psql prompts to show recovery status) |
Дата | |
Msg-id | 24080.1562855750@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status)
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > I had the same thought, but I just realized that's probably > unfriendly: at the point when the client is assembling the list of > names to send to the server, it doesn't know the server version. I > think we're probably best off assuming that any names we don't > recognize are something that got added in a newer server version and > just ignoring them. The client is not powerless to sort this out > after-the-fact: once the connection is made, they'll know the server > version and also have the option to interrogate pg_settings if they > wish. > We also need to think about how to write a test for this patch... All of the above is based on the assumption that this isn't a plain old USERSET GUC, which I'm not really seeing the argument for. OK, there might be *implementation* reasons why we would rather not deal with on-the-fly changes to the list, but there's no advantage to users in it. regards, tom lane
В списке pgsql-hackers по дате отправления: