Re: Seems to be impossible to set a NULL search_path

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Christophe Pettus <xof(at)thebuild(dot)com>
Cc: Bryn Llewellyn <bryn(at)yugabyte(dot)com>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, Tom Lane PostgreSQL <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Seems to be impossible to set a NULL search_path
Date: 2022-07-06 17:25:29
Message-ID: CAKFQuwbsg0M==0c3v8UUUrpFRH-V_MZS0Fbr-tueom4wcd5yqQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Jul 6, 2022 at 10:03 AM Christophe Pettus <xof(at)thebuild(dot)com> wrote:

>
>
> > On Jul 6, 2022, at 09:48, Bryn Llewellyn <bryn(at)yugabyte(dot)com> wrote:
> > Neither causes an error. The "show", in each case, prints the bare value
> with no quotes. It never struck me try try double quotes around the
> timezone argument. I'm shocked that they are silently accepted here and
> seem to have the same effect (in this syntax setting) as single quotes.
>
> It's really a lot easier than it is being made out to be.
>
> GUCs accept a string as a value, which might then be converted to other
> values based on the semantics of the GUC. PostgreSQL generously accepts
> three different ways of delimiting this string:
>
> 1. Single quotes (as in SQL).
> 2. Double quotes (which in SQL, yes, are used to delimit names).
> 3. No delimiter at all if there are no embedded characters that would
> terminate the value prematurely.
>
>
4. Dollar quoting

postgres=# set search_path to $$testschema$$;
SET
postgres=# show search_path;
search_path
-------------
testschema
(1 row)

Thus a more accurate syntax specification would be (at least for
search_path):

SET [ SESSION | LOCAL ] configuration_parameter { TO | = } value [, ...]

Where value is one of:
{ identifier | string_constant | DEFAULT }

And those first two are the defined terms in SQL Syntax.

That covers all four options split among the two defined types.

Now, maybe that doesn't work for other GUCs and so this level of
imprecision is acceptable...I'm ok with coming away from this conversation
with the status quo but I'm not going to try and claim there isn't anything
confusing here.

David J.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Karsten Hilbert 2022-07-06 17:45:39 Re: lifetime of the old CTID
Previous Message David G. Johnston 2022-07-06 17:12:03 Re: Seems to be impossible to set a NULL search_path