Re: Bug #6593, extensions, and proposed new patch policy - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Bug #6593, extensions, and proposed new patch policy
Date
Msg-id 1334866968-sup-9441@alvh.no-ip.org
Whole thread Raw
In response to Re: Bug #6593, extensions, and proposed new patch policy  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: Bug #6593, extensions, and proposed new patch policy  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
Excerpts from Dimitri Fontaine's message of jue abr 19 12:42:00 -0300 2012:

> What about only issuing a WARNING that the extensions are not supported
> by reassign owned in 9.1 (and probably 9.2)?

Raise a warning and then do what?  While you can continue reassigning
the rest of the objects to someone else, this doesn't help the poor
fella who's just trying to drop the owner of the extension -- it still
can't be dropped.  Moreover, since there's no ALTER OWNER command for
extensions, the user can't just change it to someone else manually.
The only option is to do DROP OWNED, which will drop the extension along
with all the objects that belong to it.  In fact, the documentation
states that the way to drop a user that owns objects is to run REASSIGN
OWNED, then DROP OWNED, (repeat for all databases), then DROP ROLE.  So
if the DBA does that, he might end up dropping the extension by
accident.

Maybe we could just add a protection that the user to which the
extension is reassigned must be a superuser or the database owner.

Remember that we're talking about REASSIGN OWNED here, which will
automatically reassign not only the extension itself, but also the
contained objects.  There is no danger that we will end up with an
inconsistent installation.  Also, if the objects in the extension have
been manually given to someone else, they will stay owned by that other
user, precisely because the code as written does not recurse.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: Alex
Date:
Subject: Re: libpq URI and regression testing
Next
From: Dimitri Fontaine
Date:
Subject: Re: Bug #6593, extensions, and proposed new patch policy