Re: ALTER OBJECT any_name SET SCHEMA name

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: ALTER OBJECT any_name SET SCHEMA name
Дата
Msg-id 26099.1288975682@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: ALTER OBJECT any_name SET SCHEMA name  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Ответы Re: ALTER OBJECT any_name SET SCHEMA name  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Список pgsql-hackers
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> 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.

> 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Daniel Farina
Дата:
Сообщение: Re: ALTER TABLE ... IF EXISTS feature?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: ALTER TABLE ... IF EXISTS feature?