Alvaro Herrera <alvhe...@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 extensions
Schema | Name | Version | Description
--------+--------------------+----------+--------------
utils | lo | 9.1devel | managing Larg
utils | unaccent | 9.1devel | text search d
utils | adminpack | 9.1devel | Administrativ
utils | moddatetime | 9.1devel | functions for
utils | 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 with schema foo feature,
rather than be introduced in the alter extension set schema patch?
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
