Alvaro Herrera wrote:
> cpacejo@clearskydata.com wrote:
> > =# REASSIGN OWNED BY user1 TO user2;
> >
> > =# SELECT typowner, relowner FROM pg_type JOIN pg_class ON typrelid =
> > relfilenode WHERE typname = 'foo';
> > -[ RECORD 1 ]---
> > typowner | 8713825
> > relowner | 16384
>
> Hmm. I guess we're missing a recursion step somewhere. I would have
> assumed that the pg_class entry would also have a dependency on the
> owner and should would have been visited in the initial loop. Strange.
I think I see what's going on here: in AlterTypeOwner the code calls
ATExecChangeOwner when it detects a composite type to start the
modification starting from the type relation's, from where it cascades
onto the type itself. However, AlterTypeOwnerInternal hasn't heard of
this trick and just changes itself and the array entry, so the pg_class
entry is not modified.
I think the bug is that shdepReassignOwned shouldn't be calling
AlterTypeOwnerInternal directly, because that routine is not of a high
enough level. We need another routine sitting between AlterTypeOwner
and AlterTypeOwnerInternal which does the real work for the former
(including calling ATExecChangeOwner for composites), after looking up
the type OID from the name list; then shdepReassignOwned should call
that new intermediate function.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services