Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, May 13, 2013 at 11:48 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Heikki Linnakangas <hlinnakangas@vmware.com> writes:
>>> 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:
> Let me propose another alternative: it would be relatively
> straightforward to allow this to work differently in extension scripts
> than it does in general;
That's just making the rules even more impossibly complicated (rules
that aren't documented, and we've not found any obvious place to
document them, so people aren't going to read whatever we do come up
with...)
The original objective of commit 880bfc328 was to simplify the rules
about search_path interpretation. I'm not really happy about adding
a bunch of different, but just as obscure, rules in the name of making
things easier to use. We'd be better off just reverting that patch IMO.
>> 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.
> Well, +1 for relaxing that restriction, no matter what else we do.
> But that only makes an accidental restore into pg_catalog less sucky,
> not less likely.
Another way to fix that inconsistency is to consider that
allow_system_table_mods should gate table creations not just drops in
pg_catalog. I'm not real sure why this wasn't the case all along ...
regards, tom lane