Heikki Linnakangas <hlinnakangas@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.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 preventdrop 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