Re: erroneous restore into pg_catalog schema

Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:
> On 09.05.2013 18:24, Robert Haas wrote:
>> In the attached new version of the patch, I added an explicit check to
>> prevent relocatable extensions from being created in pg_catalog.

> Do we really want to forbid that?

The only alternative I see is the one proposed in
http://www.postgresql.org/message-id/12365.1358098148@sss.pgh.pa.us:

>>> I think maybe what we should do is have namespace.c retain an explicit
>>> notion that "the first schema listed in search_path didn't exist", and
>>> then throw errors if any attempt is made to create objects without an
>>> explicitly specified namespace.

which is also pretty grotty. Robert pointed out that it's inconsistent
with the traditional behavior of the default setting "$user, public".
Now, we could continue to treat $user as a special case, but that's just
stacking more kluges onto the pile.

BTW, looking back over the thread, I notice we have also not done
anything about this newly-introduced inconsistency:

regression=# create table pg_catalog.t(f1 int);
CREATE TABLE
regression=# drop table pg_catalog.t;
ERROR: permission denied: "t" is a system catalog

Surely allow_system_table_mods should allow both or neither of those.

Perhaps, if we fixed that, the need to prevent table creations in
pg_catalog via search_path semantics changes would be lessened.

I believe the DROP prohibition is mainly there to prevent
drop table pg_catalog.pg_proc;
ERROR: permission denied: "pg_proc" is a system catalog
but that thinking predates the invention of pg_depend. If this
check were removed, you'd still be prevented from dropping pg_proc
because it's pinned.

regards, tom lane