> t...@sss.pgh.pa.us wrote:
>
>> b...@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.
