Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Alvaro Herrera <alvherre(at)commandprompt(dot)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.

> Well, I'm thinking that:
>  - namespace columns in the catalogs are actually all for objects that
>    live in a schema and extension do not

I'm with Alvaro on this.  If we're going to have an ALTER EXTENSION SET
SCHEMA operation, then extensions must have a well-defined schema
property, and it would be good if that connection were explicitly
represented in the catalogs.  Digging stuff out of pg_depend sucks;
we have to do it in some other cases where we didn't foresee the
connection in advance, but we can see it well enough here.

BTW, I'm not even 100% convinced that the schema shouldn't be part of
the extension's name, if we're going to make it work like this.  Is
there a reason I shouldn't be able to have both public.myextension
and testing.myextension?  If we're constraining all the objects owned by
the extension to live in a single schema, this seems perfectly feasible.

			regards, tom lane

In response to

• Re: ALTER OBJECT any_name SET SCHEMA name at 2010-11-05 16:16:37 from Dimitri Fontaine

Responses

• Re: ALTER OBJECT any_name SET SCHEMA name at 2010-11-05 17:06:59 from Dimitri Fontaine

pgsql-hackers by date

Next:	From: Tom Lane	Date: 2010-11-05 17:04:01
	Subject: Re: ALTER TABLE ... IF EXISTS feature?
Previous:	From: Daniel Farina	Date: 2010-11-05 16:31:19
	Subject: Re: ALTER TABLE ... IF EXISTS feature?