Alvaro Herrera <alvherre@commandprompt.com> writes:
> Frankly, the get_extension_namespace bit still feels wrong to me. I
> would have the namespace be present in the pg_extension catalog, even if
> it's not part of the primary key. This would let you answer the
> question: what schema did I install this extension in? (and display it
> in \dx commands etc)
dim=# \dx List of extensionsSchema | Name | Version | Description
--------+--------------------+----------+--------------utils | lo | 9.1devel | managing Largutils |
unaccent | 9.1devel | text search dutils | adminpack | 9.1devel | Administrativutils | moddatetime
| 9.1devel | functions forutils | isn | 9.1devel | data types fo
...
I've cut in there obviously, but you get the idea.
> If you don't know that, then the ability to change
> it to another schema looks incomplete. Since we're now saying that
> moving the extension to another schema is a first-class operation, I
> think the data should be represented more explicitely in the catalog
> rather than being derived from pg_depend contents.
Well, I'm thinking that:
- namespace columns in the catalogs are actually all for objects that live in a schema and extension do not
- pg_depend is a good source here, as it is for get_constraint_index and some other functions
- maybe the problem is that parts of this patch should go into the main extension's one, where there's already the
withschema foo feature, rather than be introduced in the alter extension set schema patch?
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
