Re: Re: BUG #7748: "drop owned by" fails with error message: "unrecognized object class: 1262"

Tom Lane escribi=F3:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > I disagree with this assessment, and propose the attached patch inste=
ad.
>=20
> +1 for this approach in HEAD ...
>=20
> > This is the patch for the master branch; I have not tried to backpatc=
h
> > it yet.  Conflicts are expected due to the refactoring of ALTER comma=
nds
> > by KaiGai.
>=20
> ... but I'm worried that you'd need a substantially larger patch in bac=
k
> branches, and accordingly I'm not sure this is what to do in the back
> branches.  Without that refactoring, you might need to duplicate more
> code, so it might be safer to just revert as Jeff suggested.

I had a look at what it'd take to backpatch.  For REASSIGN OWNED, you're
right that it'd require some refactoring, and it's probably not
worthwhile (the code is not really all that complicated).  However, for
DROP OWNED the proposed hunks apply fine.  Only 8.3 needs a different
patch, but it's only because whitespace is different.

So what we would end up with, is that DROP OWNED works for shared
objects (i.e. grants on tablespaces and databases are revoked), but
REASSIGN OWNED does not; so you're forced to do ALTER
DATABASE/TABLESPACE SET OWNER.

Since it's the grants that are more likely to cause headaches than
ownership when trying to drop users, I suggest that applying those
patches is the most convenient.  (We know that this is a real problem
because of the bug reports we've gotten.)

> The documentation also needs more work than what you suggest in your
> followup.  The command reference pages should explicitly say that they
> operate on both objects in the current database and shared objects.
> Explicitly defining shared objects as databases and tablespaces
> wouldn't hurt any.
>=20
> It also strikes me that where you suggest "Because REASSIGN OWNED does
> not affect objects in other databases ...", it might be clearer to say
> "Because REASSIGN OWNED does not affect objects within other databases
> ...", which makes the idea of containment a little stronger.

Okay, I will revise those proposed docs changes.

--=20
=C1lvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services