Tom Lane <t...@sss.pgh.pa.us> writes: > OK, so I guess I'm missing why the extension code is looking for stuff > dependent on the pg_catalog schema. That schema certainly doesn't > belong to any extension.
Exactly. We're on the same page here, full agreement. So the extension patch is not considering pg_catalog in any special way here, and the problem comes from contrib/adminpack which installs its functions into pg_catalog, yet is not part of core. 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… > In any case, your proposed hack above is effectively assuming that > there's only one pinned schema, which is untrue now and is likely to > become even less true in the future. So I don't think we can go that way. 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. We could use get_extension_namespace() just after recoding the dependency and error out if we don't find the arguments we gave to recordDependencyOn() so that we're not duplicating code. That will cover any pinned schema. I'm preparing a patch to do that. 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… Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers