Re: ALTER OBJECT any_name SET SCHEMA name

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: ALTER OBJECT any_name SET SCHEMA name
Дата
Msg-id 26637.1288977412@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:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> 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.

> Are you proposing that an extension object is schema qualified?

Dunno, I'm just asking the question.  If it isn't, why not?

Here's another question: if an extension's objects live (mostly or
entirely) in schema X, what happens if the possibly-unprivileged owner
of schema X decides to drop it?  If the extension itself is considered
to live within the schema, then "the whole extension goes away" seems
like a natural answer.  If not, you've got some problems.

> Would we lower creating extension privileges to database owners, too,
> rather than only superusers?

That seems like an orthogonal question.  I can see people wanting both
behaviors though.  Maybe an extension's config file should specify the
privs needed to install it?
        regards, tom lane


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

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Re: ALTER OBJECT any_name SET SCHEMA name
Следующее
От: Marti Raudsepp
Дата:
Сообщение: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+