Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:
> I notice you can use most of the RENAME TO commands in postgres to
> rename system objects. Renaming a system table is disallowed:
> test=# alter table pg_namespace rename to blah;
> ERROR: permission denied: "pg_namespace" is a system catalog
> But mucking with any other system object is not:
> test=# alter function abbrev(inet) rename to bad;
> ALTER FUNCTION
> Is there logic in that?
Yes: superusers should be allowed to shoot themselves in the foot
whenever possible.
We *know* the code will stop working if you rename a system table or
index, because those things are referred to *by name* in the C code.
So that prohibition seems reasonable. On the other end of the scale,
there is no reason whatever to prohibit someone from mucking with the
inet datatype to their heart's content. It's only builtin as an
artifact of our packaging, not because anything depends on it.
It's likely that there are some pg_proc entries that you can break the
system beyond repair by renaming, but I'd expect they are a relatively
small minority (the system's hardwired references are by OID not name).
We shouldn't put a blanket prohibition on it to prevent problems we
aren't even certain exist.
As an example of why superusers should have as few restrictions as
possible, I refer you to the 7.4.2 release notes:
http://www.postgresql.org/docs/7.4/static/release.html#RELEASE-7-4-2
Without the ability for superusers to muck with the system catalogs,
we'd have had no choice but to force initdb for 7.4.2 to fix those
errors.
regards, tom lane