From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
cc: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>,
        pavel.stehule@gmail.com, a.zakirov@postgrespro.ru,
        pgsql-hackers@postgresql.org
Subject: Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs
In-reply-to: <20180320003951.GA4963@paquier.xyz>
References: <20180316.173433.146279605.horiguchi.kyotaro@lab.ntt.co.jp>
 <CAFj8pRDbYZQHPH+itQ2dfv6ytVGMEt21PtmDZotGMOeVjS-KjA@mail.gmail.com>
 <20180316121554.GA2552@paquier.xyz>
 <20180319.144909.253960140.horiguchi.kyotaro@lab.ntt.co.jp>
 <2637.1521501336@sss.pgh.pa.us> <20180320003951.GA4963@paquier.xyz>
Comments: In-reply-to Michael Paquier <michael@paquier.xyz>
	message dated "Tue, 20 Mar 2018 09:39:51 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <10036.1521515233.1@sss.pgh.pa.us>
Date: Mon, 19 Mar 2018 23:07:13 -0400
Message-ID: <10037.1521515233@sss.pgh.pa.us>
Precedence: bulk

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