> On Jul 6, 2022, at 09:48, Bryn Llewellyn <b...@yugabyte.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.
That's pretty much it. That's the rule. In the case of search_path, the
argument is "a list of SQL names, including possibly one or none". Now, one
could perhaps argue that PostgreSQL is being overly-accepting by allowing #2,
since it does create odd situations like you describe with search_path, quotes,
and so forth (there might be others, but search_path is the only one that jumps
to mind). That being said, it does, it has for decades, and there's really no
compelling reason to change it. Of all the things that might be described as
"shocking" about PostgreSQL, "GUCs allow double-quotes to delimit values for
convenience and historic reasons" is not quite the one I would pick.
