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+TgmoYr3RDwxbj_z+0Kten3iNQnboKtY5kBFSnDujSrcaBKVg@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
List pgsql-hackers
On Wed, Apr 17, 2013 at 2:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I think this breaks contrib/adminpack, and perhaps other extensions.
> They'd not be hard to fix with script changes, but they'd be broken.
>
> In general, we would now have a situation where relocatable extensions
> could never be installed into pg_catalog.  That might be OK, but at
> least it would need to be documented.
>
> Also, I think we'd be pretty much hard-wiring the decision that pg_dump
> will never dump objects in pg_catalog, because its method for selecting
> the creation schema won't work in that case.  That probably is all right
> too, but we need to realize it's a consequence of this.

These are all good points.  I'm uncertain whether they are sufficient
justification for abandoning this idea and looking for another
solution, or whether we should live with them.  Any thoughts?

> As far as the code goes, OK except I strongly disapprove of removing
> the comment about temp_missing at line 3512.  The coding is not any less
> a hack in that respect for having been pushed into a subroutine.  If
> you want to rewrite the comment, fine, but failing to point out that
> something funny is going on is not a service to readers.

OK, how about something like this: "Choose default creation namespace
(but note that temp_missing, if set, will trump this value)."

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



pgsql-hackers by date:

Previous
From: Shaun Thomas
Date:
Subject: Re: Fast promotion, loose ends
Next
From: Robert Haas
Date:
Subject: Re: Enabling Checksums