Tom Lane <tgl@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
