Heikki Linnakangas <hlinnakan...@vmware.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.1358098...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
