Search Postgresql Archives

Re: Seems to be impossible to set a NULL search_path

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



tgl@xxxxxxxxxxxxx wrote:

bryn@xxxxxxxxxxxx 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.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux