Skip site navigation (1) Skip section navigation (2)

Re: Extensions support for pg_dump, patch v27

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, 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:51:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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

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.


Dimitri Fontaine     PostgreSQL : Expertise, Formation et Support

In response to


pgsql-hackers by date

Next:From: Richard BroersmaDate: 2011-01-26 20:05:39
Subject: Re: [HACKERS] Seeking Mentors for Funded Reviewers
Previous:From: Tom LaneDate: 2011-01-26 19:49:35
Subject: Re: [HACKERS] Seeking Mentors for Funded Reviewers

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group