Re: Extensions support for pg_dump, patch v27 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Extensions support for pg_dump, patch v27
Date
Msg-id 23650.1296070526@sss.pgh.pa.us
Whole thread Raw
In response to Re: Extensions support for pg_dump, patch v27  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: Extensions support for pg_dump, patch v27  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> So in his tests, Itagaki was tempted to issue the following statement:

>   CREATE EXTENSION adminpack WITH SCHEMA pg_catalog;

> That's supposed to register a dependency from the extension to its
> declared hosting schema (adminpack is not relocatable so that entirely
> depends on its script - which forces pg_catalog).

> Then you get the same problems as with any other object that lives into
> this schema, pg_dump will avoid dumping its definition ...

Mph.  Although such an extension should certainly carry a dependency on
the schema it's using, I'm not sure that it makes sense to consider that
the extension (as opposed to its contained objects) belongs to the
schema.  If we think that extensions live inside schemas then it's
logically difficult for an extension to own objects scattered across
multiple schemas, which is surely a restriction we do not want.  So I'd
have expected that extensions use unqualified names, like languages or
tablespaces.  That being the case, there is no reason why pg_dump ought
to be making any such test.

There are places where pg_dump refuses to dump objects contained in
pg_catalog on the grounds that they're system objects, but that
heuristic ought not apply to extensions IMO, even if you don't agree
with the conclusion of the preceding paragraph.  Any extension is, by
definition, not built-in.

> Well I proposed is nothing more than a crock.  What I'd like us to do
> instead is ERRORing out when you want to use pg_catalog for an
> extension.

Right offhand I'm not seeing the need for such a restriction, though
certainly I'd not cry a lot if we had to impose it.  ISTM what we've got
here is some bogus what-to-dump rules in pg_dump.  Extensions should
always be dumped.

> What do we want to do with adminpack?  Including its functions into
> core, or have it use another schema?  I don't think an extension
> installing its objects into pg_catalog is that good an idea

I'm trying to avoid having an opinion on that.  The reasons for it might
or might not be very good, but I'd rather that the extension mechanism
didn't break the ability for people to make such decisions.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: SSI patch version 14
Next
From: Tom Lane
Date:
Subject: Re: Explain with schema