Dimitri Fontaine <dimi...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers