Re: Bug #6593, extensions, and proposed new patch policy
От | Alvaro Herrera |
---|---|
Тема | Re: Bug #6593, extensions, and proposed new patch policy |
Дата | |
Msg-id | 1334866968-sup-9441@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: Bug #6593, extensions, and proposed new patch policy (Dimitri Fontaine <dimitri@2ndQuadrant.fr>) |
Ответы |
Re: Bug #6593, extensions, and proposed new patch policy
|
Список | 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 по дате отправления: