Re: BUG #13666: REASSIGN OWNED BY doesn't affect the relation underlying composite type
От | Alvaro Herrera |
---|---|
Тема | Re: BUG #13666: REASSIGN OWNED BY doesn't affect the relation underlying composite type |
Дата | |
Msg-id | 20151211223025.GX2763@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: BUG #13666: REASSIGN OWNED BY doesn't affect the relation underlying composite type (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: BUG #13666: REASSIGN OWNED BY doesn't affect the relation
underlying composite type
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: