tgl@xxxxxxxxxxxxx wrote:bryn@xxxxxxxxxxxx writes: 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?
Yes, that point is very well taken. But I like to know the limit's of what's technically possible. |
