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
> 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;
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
In response to
pgsql-hackers by date
|Next:||From: Richard Broersma||Date: 2011-01-26 20:05:39|
|Subject: Re: [HACKERS] Seeking Mentors for Funded Reviewers|
|Previous:||From: Tom Lane||Date: 2011-01-26 19:49:35|
|Subject: Re: [HACKERS] Seeking Mentors for Funded Reviewers |