Rework internals of changing a type's ownership
authorAlvaro Herrera <alvherre@alvh.no-ip.org>
Mon, 21 Dec 2015 22:49:15 +0000 (19:49 -0300)
committerAlvaro Herrera <alvherre@alvh.no-ip.org>
Mon, 21 Dec 2015 22:49:15 +0000 (19:49 -0300)
commitf9643d0d6dd303a6733f8b3015c7659680e7fe42
treea4a00aa814cb350a777065a9c6fe7c73594d16e7
parent653530c8b1963bf91e19d03305dd0df5ad776bec
Rework internals of changing a type's ownership

This is necessary so that REASSIGN OWNED does the right thing with
composite types, to wit, that it also alters ownership of the type's
pg_class entry -- previously, the pg_class entry remained owned by the
original user, which caused later other failures such as the new owner's
inability to use ALTER TYPE to rename an attribute of the affected
composite.  Also, if the original owner is later dropped, the pg_class
entry becomes owned by a non-existant user which is bogus.

To fix, create a new routine AlterTypeOwner_oid which knows whether to
pass the request to ATExecChangeOwner or deal with it directly, and use
that in shdepReassignOwner rather than calling AlterTypeOwnerInternal
directly.  AlterTypeOwnerInternal is now simpler in that it only
modifies the pg_type entry and recurses to handle a possible array type;
higher-level tasks are handled by either AlterTypeOwner directly or
AlterTypeOwner_oid.

I took the opportunity to add a few more objects to the test rig for
REASSIGN OWNED, so that more cases are exercised.  Additional ones could
be added for superuser-only-ownable objects (such as FDWs and event
triggers) but I didn't want to push my luck by adding a new superuser to
the tests on a backpatchable bug fix.

Per bug #13666 reported by Chris Pacejo.

This is a backpatch of commit 756e7b4c9db1 to branches 9.1 -- 9.4.
src/backend/catalog/pg_shdepend.c
src/backend/commands/tablecmds.c
src/backend/commands/typecmds.c
src/include/commands/typecmds.h
src/test/regress/expected/dependency.out
src/test/regress/sql/dependency.sql