Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Feb 1, 2013 at 5:13 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>>> I wonder whether it'd not be a better idea to forbid specifying
>>> pg_catalog as the target schema for relocatable extensions.
We should do that, yes. Rationale: it's only documenting an existing
restriction that you just explained we can't get rid of. Want me to send
a patch (tomorrow)?
> I understand the temptation to forbid pg_catalog as the target schema
> for relocatable extensions, or indeed for object creation in general.
Those two cases are not to be mixed.
> The fact that you can't, for example, go back and drop the objects
> later is a real downer. On the other hand, from a user perspective,
> it's really tempting to want to create certain extensions (adminpack,
> for example) in such a way that they appear to be "part of the system"
> rather than something that lives in a user schema. Had we some other
It's easy to do that in the extension's control properties:
relocatable = false schema = pg_catalog
And the adminpack extension is already set that way. It's then part of
the system and you can still remove it. The only think you can not do is
move its objects in another schema, and I don't much see the point.
> solution to that problem (a second schema that behaves like pg_catalog
> but is empty by default and allows drops?) we might alleviate the need
> to put stuff in pg_catalog per se.
We had extensive talks about that when cooking the extension patch, and
that almost killed it. I think it took about a full year to get back on
our feet again. The only thing I know about that search_path can of
worms is that I will stay away from it as much as possible, and
wholeheartedly advice anyone to do the same.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support