Fix multiranges to behave more like dependent types.
commit3e8235ba4f9cc3375b061fb5d3f3575434539b5f
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 14 Feb 2024 16:30:39 +0000 (14 11:30 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 14 Feb 2024 16:30:39 +0000 (14 11:30 -0500)
tree44b71342fadc8cb3dc5e0fe50359ee2e23c31506
parentbd8fc1677b88ed80e4e00e0e46401ec537952482
Fix multiranges to behave more like dependent types.

For most purposes, multiranges act like dependent objects of the
associated range type: you can't create them separately or drop them
separately.  This is like the way that autogenerated array types
behave.  However, a couple of points were overlooked: array types
automatically track the ownership of their base type, and array types
do not have their own permissions but use those of the base type,
while multiranges didn't emulate those behaviors.  This is fairly
broken, mainly because pg_dump doesn't think it needs to worry about
multiranges as separate objects, and thus it fails to dump/restore
ownership or permissions of multiranges.

There's no apparent value in letting a multirange diverge from
its parent's ownership or permissions, so let's make them act like
arrays in these respects.  However, we continue to let multiranges
be renamed or moved to a different schema independently of their
parent, since that doesn't break anything.

Discussion: https://postgr.es/m/1580383.1705343264@sss.pgh.pa.us
src/backend/catalog/aclchk.c
src/backend/catalog/pg_type.c
src/backend/commands/typecmds.c
src/bin/pg_dump/pg_dump.c
src/test/regress/expected/dependency.out
src/test/regress/expected/multirangetypes.out
src/test/regress/sql/multirangetypes.sql