Cannot create a type in pg_catalog

Dave Page <dpage@postgresql.org> writes:

Should this work, or at least give a more appropriate error message?
demo=# CREATE TYPE pg_catalog.mytype AS (data text);
ERROR: permission denied to create "pg_catalog.mytype"
DETAIL: System catalog modifications are currently disallowed.

Seems like a perfectly appropriate error message to me: it's disallowed.

regards, tom lane

Tom Lane wrote:

Dave Page <dpage@postgresql.org> writes:

Should this work, or at least give a more appropriate error message?
demo=# CREATE TYPE pg_catalog.mytype AS (data text);
ERROR: permission denied to create "pg_catalog.mytype"
DETAIL: System catalog modifications are currently disallowed.

Seems like a perfectly appropriate error message to me: it's disallowed.

I see three issues:

- it's only partially disallowed - why can I create a function, but not
a type? Shouldn't both be either allowed or disallowed?

- The description in the docs of pg_authid.rolcatupdate reads:

Role may update system catalogs directly. (Even a superuser may not do
this unless this column is true)

However, even with it set to true, I cannot do so. Of course, this
depends on whether you define 'system catalogs' as the tables in
pg_catalog, or the pg_catalog schema itself. Either way, something's a
little wonky.

- "are currently disallowed" implies that sometimes it is allowed. How
does one control that, or is it implying something that is not the case,
or only the case in unusual circumstances such as a standalone backend?

Note that I'm making no comment on whether or not I should be able to do
what I'm suggesting (thought preventing it will break adminpack) - just
that we have some inconsistencies at the very least.

Regards, Dave

Dave Page wrote:

- "are currently disallowed" implies that sometimes it is allowed. How
does one control that, or is it implying something that is not the case,
or only the case in unusual circumstances such as a standalone backend?

It is allowed in standalone mode AFAIR (maybe when specifying a flag
like -P or -O).

--
Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC
"No renuncies a nada. No te aferres a nada."

Alvaro Herrera <alvherre@commandprompt.com> writes:

Dave Page wrote:

- "are currently disallowed" implies that sometimes it is allowed. How
does one control that, or is it implying something that is not the case,
or only the case in unusual circumstances such as a standalone backend?

It is allowed in standalone mode AFAIR (maybe when specifying a flag
like -P or -O).

Yeah, you need one of those switches, I can never remember which is
which without looking.

The actual prohibition is on inserting a new pg_class row, which Dave's
command is trying to do because he's trying to create a composite type.

regards, tom lane

Tom Lane wrote:

Alvaro Herrera <alvherre@commandprompt.com> writes:

Dave Page wrote:

- "are currently disallowed" implies that sometimes it is allowed. How
does one control that, or is it implying something that is not the case,
or only the case in unusual circumstances such as a standalone backend?

It is allowed in standalone mode AFAIR (maybe when specifying a flag
like -P or -O).

Yeah, you need one of those switches, I can never remember which is
which without looking.

The actual prohibition is on inserting a new pg_class row, which Dave's
command is trying to do because he's trying to create a composite type.

If thats the case, then there's another inconsistency as I can insert a
pg_class row manually without any problems:

demo=# INSERT INTO pg_class (relname, relnamespace, reltype, relowner,
relam, relfilenode, reltablespace, relpages, reltuples, reltoastrelid,
reltoastidxid, relhasindex, relisshared, relkind, relnatts, relchecks,
reltriggers, relukeys, relfkeys, relrefs, relhasoids, relhaspkey,
relhasrules, relhassubclass, relfrozenxid) VALUES ('x', 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, FALSE, FALSE, 't', 0, 0, 0, 0, 0, 0, FALSE, FALSE, FALSE,
FALSE, '0');
INSERT 17943 1

Regards, Dave

Dave Page <dpage@postgresql.org> writes:

Tom Lane wrote:

The actual prohibition is on inserting a new pg_class row, which Dave's
command is trying to do because he's trying to create a composite type.

If thats the case, then there's another inconsistency as I can insert a
pg_class row manually without any problems:

Right, that's the end of it that's protected by rolcatupdate. The
check that is firing on you is in heap_create(), which is invoked
for composite types.

The whole allow_system_table_mods mechanism dates from Berkeley days,
and I guess you could argue that we might not need it anymore given
the improvements since then in ACL enforcement. I'm not in a big
hurry to rip it out though. Not being allowed to TRUNCATE pg_class
seems like a Good Thing to me.

regards, tom lane

Tom Lane wrote:

Dave Page <dpage@postgresql.org> writes:

Tom Lane wrote:

The actual prohibition is on inserting a new pg_class row, which Dave's
command is trying to do because he's trying to create a composite type.

If thats the case, then there's another inconsistency as I can insert a
pg_class row manually without any problems:

Right, that's the end of it that's protected by rolcatupdate. The
check that is firing on you is in heap_create(), which is invoked
for composite types.

The whole allow_system_table_mods mechanism dates from Berkeley days,
and I guess you could argue that we might not need it anymore given
the improvements since then in ACL enforcement. I'm not in a big
hurry to rip it out though. Not being allowed to TRUNCATE pg_class
seems like a Good Thing to me.

Well, yeah, that does seem like a good foot-guard. Perhaps if/when we
get a separate truncate privilege would be a more appropriate time to
look at cleaning it up.

Regards, Dave.