Re: refactoring a database owner without "reassign owned" - Mailing list pgsql-general

From Tom Lane
Subject Re: refactoring a database owner without "reassign owned"
Date
Msg-id 14513.1368486338@sss.pgh.pa.us
Whole thread Raw
In response to Re: refactoring a database owner without "reassign owned"  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-general
Jeff Janes <jeff.janes@gmail.com> writes:
> On Mon, May 13, 2013 at 2:00 PM, Alvaro Herrera <alvherre@2ndquadrant.com>wrote:
>> Jeff Janes escribi�:
>>> I think "reassign owned" should detect that it is being invoked on the
>>> internal user (as it does now) but then instead of refusing to run, it
>>> should DWIM.

>> Hm, so what would you have it do, precisely?

>> From the users perspective, I would have it reassign ownership of exactly
> those objects which are not "required by the database system", as the error
> message puts it.

ISTM this is precisely *not* what REASSIGN OWNED should do.  Its charter
is to reassign all objects owned by the target role, not to second-guess
which ones the user meant.

I can see the possible value in a tool that would do what you suggest,
but I'm wary of sticking that functionality into REASSIGN OWNED.  In
practice, it seems likely that people who are in this kind of fix would
need more fine-grained control than that anyway.  Perhaps the right
thing is something close to your hack with pg_dump, wherein the tool
produces a file of ALTER OWNER commands and then the user can hand-edit
that before pulling the trigger.

            regards, tom lane


pgsql-general by date:

Previous
From: Jeff Janes
Date:
Subject: Re: refactoring a database owner without "reassign owned"
Next
From: S H
Date:
Subject: Re: Vacuum problem