• Alvaro Herrera's avatar
    Rework internals of changing a type's ownership · 756e7b4c
    Alvaro Herrera authored
    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.
    
    Backpatch to 9.5.
    
    (I would back-patch this all the way back, except that it doesn't apply
    cleanly in 9.4 and earlier because 59367fdf wasn't backpatched.  If we
    decide that we need this in earlier branches too, we should backpatch
    both.)
    756e7b4c
dependency.out 5.62 KB