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 48E1391E-5A21-4736-B4B1-8B9468ECAFD4@yugabyte.com
Whole thread Raw
In response to Re: Seems to be impossible to set a NULL search_path  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Seems to be impossible to set a NULL search_path  (Adrian Klaver <adrian.klaver@aklaver.com>)
List pgsql-general
tgl@sss.pgh.pa.us wrote:

bryn@yugabyte.com writes:

...I'd assumed that the arguments of "set search_path" had to be SQL names...

search_path's value is not a SQL name. It's a list of SQL names wrapped in a string ... and the list can be empty.

I was informed by this precedent:

truncate table u1.t1, t2;

It uses a comma-separated list of optionally qualified  SQL names.

And this:

«
CREATE SCHEMA schema_name ...
»

It requires a single unqualified SQL name.

And then this:

«
SET [ SESSION | LOCAL ] configuration_parameter { TO | = } { value | 'value' | DEFAULT }

value — New value of parameter. Values can be specified as... identifiers... or comma-separated lists of these, as appropriate for the particular parameter...
»

Notice that the token « value » in the syntax is not in quotes. I took it to mean (for "set search_path" a SQL name that you would type bare when it's simple and surrounded by double quotes when it's exotic—in line with the much broader general rule.

And I did ad hoc tests like these.

create schema "s1, s2";
create table "s1, s2".t(k int);
insert into "s1, s2".t(k) values(42);
set search_path = "s1, s2";
select k from t;

After all, "s1, s2" is a perfectly legal SQL name—even though folks usually have rules of practice to avoid exotic names like these.

I saw that the test behaves the same if I use this:

set search_path = 's1, s2';

I put that down to an unnecessary and confusing forgiveness that got grandfathered it.

So I'm very confused by your comment. What am I missing?.

A bit off topic: I'm not sure how you came to the conclusion that superusers can't write into pg_catalog.  They can.

With tests like these:

\c demo postgres
create table pg_catalog.t(n int);

It fails with this:

42501: permission denied to create "pg_catalog.t"

I did note this detail: "System catalog modifications are currently disallowed." Is there a configuration parameter that controls this?

I don't see much point in being paranoid... if an adversary has already obtained superuser privileges

Yes, that point is very well taken. But I like to know the limit's of what's technically possible.

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Seems to be impossible to set a NULL search_path
Next
From: Adrian Klaver
Date:
Subject: Re: Seems to be impossible to set a NULL search_path