Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs
Дата
Msg-id 10037.1521515233@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Список pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:
> On Mon, Mar 19, 2018 at 07:15:36PM -0400, Tom Lane wrote:
>> This is a good thing not least because all the GUC_LIST_QUOTE variables
>> are in core.  I've been trying to think of a way that we could have
>> correct behavior for variables that the core backend doesn't know about
>> and whose extension shlibs aren't currently loaded, and I can't come up
>> with one.  So I think that in practice, we have to document that
>> GUC_LIST_QUOTE is unsupported for extension variables

> I would propose to add a sentence on the matter at the bottom of the
> CREATE FUNCTION page.  Even with that, the handling of items in the list
> is incorrect with any patches on this thread: the double quotes should
> be applied to each element of the list, not the whole list.

No, because all the places we are worried about are interpreting the
contents of proconfig or setconfig columns, and we know that that info
has been through flatten_set_variable_args().  If that function thought
that GUC_LIST_QUOTE was applicable, it already did the appropriate
quoting, and we can't quote over that without making a mess.  But if it
did not think that GUC_LIST_QUOTE was applicable, then its output can
just be treated as a single string, and that will work fine.

Our problem basically is that if we don't know the variable that was
being processed, we can't be sure whether GUC_LIST_QUOTE was used.
I don't currently see a solution to that other than insisting that
GUC_LIST_QUOTE only be used for known core GUCs.

            regards, tom lane


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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: file cloning in pg_upgrade and CREATE DATABASE
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: configure's checks for --enable-tap-tests are insufficient