Re: refactoring a database owner without "reassign owned"

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

In response to

Browse pgsql-general by date

  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"