From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Vincent Veyron <vv(dot)lists(at)wanadoo(dot)fr>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: refactoring a database owner without "reassign owned" |
Date: | 2013-05-13 23:05:38 |
Message-ID: | 14513.1368486338@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> On Mon, May 13, 2013 at 2:00 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | S H | 2013-05-14 02:10:30 | Re: Vacuum problem |
Previous Message | Jeff Janes | 2013-05-13 22:12:04 | Re: refactoring a database owner without "reassign owned" |