> On Jul 6, 2022, at 09:48, Bryn Llewellyn <bryn@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
doublequotes 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.
PostgreSQLgenerously 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
possiblyone or none". Now, one could perhaps argue that PostgreSQL is being overly-accepting by allowing #2, since it
doescreate odd situations like you describe with search_path, quotes, and so forth (there might be others, but
search_pathis the only one that jumps to mind). That being said, it does, it has for decades, and there's really no
compellingreason to change it. Of all the things that might be described as "shocking" about PostgreSQL, "GUCs allow
double-quotesto delimit values for convenience and historic reasons" is not quite the one I would pick.
