Re: erroneous restore into pg_catalog schema - Mailing list pgsql-hackers

From Robert Haas
Subject Re: erroneous restore into pg_catalog schema
Date
Msg-id CA+TgmoZa_V=Gee82C8xYVpnOb_EZ636usB8uB54LR=Bd-hmo-g@mail.gmail.com
Whole thread Raw
In response to Re: erroneous restore into pg_catalog schema  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: erroneous restore into pg_catalog schema  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, May 13, 2013 at 11:48 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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:

Let me propose another alternative: it would be relatively
straightforward to allow this to work differently in extension scripts
than it does in general; it's already contingent in whether we're in
bootstrap-processing mode, and there's no reason we couldn't add some
other flag that gets set during extension-script processing mode, if
there isn't one already, and make it contingent on that also.  I think
what we're concerned with is mostly preventing accidental object
creation in pg_catalog, and allowing extensions to be created there
wouldn't interfere with that.

> 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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Parallel Sort
Next
From: Tom Lane
Date:
Subject: Re: erroneous restore into pg_catalog schema