From: Tom Lane <tgl@sss.pgh.pa.us>
To: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
cc: michael@paquier.xyz, 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: <20180319.144909.253960140.horiguchi.kyotaro@lab.ntt.co.jp>
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>
Comments: In-reply-to Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
	message dated "Mon, 19 Mar 2018 14:49:09 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2636.1521501336.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 19 Mar 2018 19:15:36 -0400
Message-ID: <2637.1521501336@sss.pgh.pa.us>
Precedence: bulk

Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes:
> At Fri, 16 Mar 2018 21:15:54 +0900, Michael Paquier <michael@paquier.xyz=
> wrote in <20180316121554.GA2552@paquier.xyz>
>> Let's be clear.  I have listed all the variables in the patch to gather
>> more easily opinions, and because it is easier to review the whole stac=
k
>> this way. I personally think that the only variables where the patch
>> makes sense are:
>> - DateStyle
>> - search_path
>> - plpgsql.extra_errors
>> - plpgsql.extra_warnings
>> - wal_consistency_checking
>> So I would be incline to drop the rest from the patch.  If there are
>> authors of popular extensions willing to get this support, let's update
>> the list once they argue about it and only if it makes sense.  However,
>> as far as I can see, there are no real candidates.  So let's keep the
>> list simple.

> FWIW +1 from me. It seems reasonable as the amendment to the
> current status.

It suddenly struck me that the scope of the patch is wider than it needs
to be.  We don't need special behavior for all GUC_LIST variables, only
for GUC_LIST_QUOTE variables.  (For example, SET datestyle =3D 'iso, mdy'
works just as well as SET datestyle =3D iso, mdy.)

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 (and, perhaps,
enforce this in DefineCustomStringVariable? or is that cure worse than
the disease?)

			regards, tom lane