Re: Bug #6593, extensions, and proposed new patch policy

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug #6593, extensions, and proposed new patch policy
Date: 2012-04-19 20:30:04
Message-ID: 1334866968-sup-9441@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2012-04-19 21:08:38 Re: Bug #6593, extensions, and proposed new patch policy
Previous Message Alex 2012-04-19 20:06:05 Re: libpq URI and regression testing