Re: Extensions support for pg_dump, patch v27

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
Cc: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, David Fetter <david(at)fetter(dot)org>, PostgreSQL-Hackers <pgsql-hackers(at)postgresql(dot)org>, Dave Page <dpage(at)postgresql(dot)org>, Guillaume Lelarge <guillaume(at)lelarge(dot)info>
Subject: Re: Extensions support for pg_dump, patch v27
Date: 2011-01-26 19:35:26
Message-ID: 23650.1296070526@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-01-26 19:39:27 Re: Explain with schema
Previous Message Alvaro Herrera 2011-01-26 19:25:27 Re: SSI patch version 14