Re: Extensions support for pg_dump, patch v27

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> 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.

Well yes, extension are not living in a schema, we just offer users a
way to influence the script as far as where the extension's objects are
to be found and register a dependency so that it's easy to remember what
the users asked. So that for example we are able to act the same way on
pg_restore.

Now, pg_dump makes no such test already, but a query is using a JOIN to
list extensions and their target schema, where it's possible that the
target has not been recorded by recordDependencyOn(): in this case the
whole extension's is filtered out of the resultset. Quick and dirty
fix, I proposed to LEFT JOIN in the pg_dump query…

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

Agreed. The problem we're having here is how to implement all that yet
fully support adminpack. The design we're talking about is the same.

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

Agreed. Trying to solve an implementation detail, and that's the easier
way to prevent users from shooting themselves in the foot here.

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

You still can do one of the following commands, where you're not having
a say on the real schema that adminpack will use because it's not
relocatable and not paying attention to @extschema@, but apart from this
lie everything will just work. I'd be happy to ship with such a lie,
but I can see why people want something different.

CREATE EXTENSION adminpack;
CREATE EXTENSION adminpack WITH SCHEMA utils;

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support