Re: Seems to be impossible to set a NULL search_path
От | Christophe Pettus |
---|---|
Тема | Re: Seems to be impossible to set a NULL search_path |
Дата | |
Msg-id | D2AA1786-A8C3-43C5-B5BA-5D799F10B424@thebuild.com обсуждение исходный текст |
Ответ на | Re: Seems to be impossible to set a NULL search_path (Bryn Llewellyn <bryn@yugabyte.com>) |
Ответы |
Re: Seems to be impossible to set a NULL search_path
|
Список | pgsql-general |
> 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.
В списке pgsql-general по дате отправления: