Re: ALTER OBJECT any_name SET SCHEMA name - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ALTER OBJECT any_name SET SCHEMA name
Date
Msg-id 26637.1288977412@sss.pgh.pa.us
Whole thread Raw
In response to Re: ALTER OBJECT any_name SET SCHEMA name  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: ALTER OBJECT any_name SET SCHEMA name
List 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 by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: ALTER OBJECT any_name SET SCHEMA name
Next
From: Marti Raudsepp
Date:
Subject: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+