Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: michael(at)paquier(dot)xyz, pavel(dot)stehule(at)gmail(dot)com, a(dot)zakirov(at)postgrespro(dot)ru, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs
Date: 2018-03-20 03:37:47
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

At Mon, 19 Mar 2018 23:07:13 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in <10037(dot)1521515233(at)sss(dot)pgh(dot)pa(dot)us>
> Michael Paquier <michael(at)paquier(dot)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.

The documentation of SET command says as the follows. (CREATE
FUNCTION says a bit different but seems working in the same way)

> SET [ SESSION | LOCAL ] configuration_parameter { TO | = } { value | 'value' | DEFAULT }

> value
> New value of parameter. Values can be specified as string
> constants, identifiers, numbers, or comma-separated lists of
> these, as appropriate for the particular parameter. DEFAULT can
> be written to specify resetting the parameter to its default
> value (that is, whatever value it would have had if no SET had
> been executed in the current session).

According to this description, a comma-separated list enclosed
with single quotes is a valid list value. (I remenber I was
trapped by the description.)

I should be stupid but couldn't we treat quoted comma-separated
list as a bare list if it is the only value in the argument? I
think no one sets such values containing commas as
temp_tablespaces, *_preload_libraries nor search_path.

But of course it may break something and may break some


Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
expand_single_list_value_of_setstmt.patch text/x-patch 1.7 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-03-20 04:01:02 Re: IndexJoin memory problem using spgist and boxes
Previous Message Etsuro Fujita 2018-03-20 03:32:51 Re: inserts into partitioned table may cause crash