Re: Seems to be impossible to set a NULL search_path - Mailing list pgsql-general

From Bryn Llewellyn
Subject Re: Seems to be impossible to set a NULL search_path
Date
Msg-id 3BF74142-24B5-4159-BB2F-FDD22BD2B89F@yugabyte.com
Whole thread Raw
In response to Re: Seems to be impossible to set a NULL search_path  (Adrian Klaver <adrian.klaver@aklaver.com>)
Responses Re: Seems to be impossible to set a NULL search_path  (Christophe Pettus <xof@thebuild.com>)
Re: Seems to be impossible to set a NULL search_path  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-general
adrian.klaver@aklaver.com wrote:

Not sure what your point is?

Try these two:

set timezone = 'America/New_York';
show timezone;

set timezone = "America/New_York";
show timezone;

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. (I realize that quoting is required.) This comes as shock. It seems to be a "solution" to problem that I don't have—and it brings confusion. Try this:

set search_path = '"x"'; -- Hard to read. It's double-quoted x surrounded by single quotes.
show search_path;

This is the result:

 search_path 
-------------
 """x"""

That's a run of three double quotes each side of x. (For sport, try a single-quoted x surrounded by double-quotes.) I have no idea what this means—or why it's allowed. But the fact that the quoting has different effects in my different examples led me to say what I did.

When I read "string" in doc, then I understand that a manifest string constant (like the timezone setting that I used) must be single-quoted in SQL statements and the like. Not double-quoted.

All this seems to be 100% distinct from the discussion of exotic SQL names that have to be double-quoted in SQL syntax where a simple name doesn't need this (be can be double quoted if you want).

These two produces different outcomes:

select 'cat';
select "cat";

I won't risk explaining why I'm, not at all surprised.

Enough! I'll assume that we're talking past each other. But the cost/benefit of trying to work out why comes out wrong—so I'll stop. Thanks for trying to help me.

pgsql-general by date:

Previous
From: Aleksander Łukasz
Date:
Subject: Why does pg_statio_user_tables report heap_blks_hit after index only scan?
Next
From: Christophe Pettus
Date:
Subject: Re: Seems to be impossible to set a NULL search_path