ALTER TYPE OWNER fails to recurse to multirange

d=# create type varbitrange as range (subtype = varbit);
CREATE TYPE
d=# \dT+
List of data types
Schema | Name | Internal name | Size | Elements | Owner | Access privileges | Description
--------+------------------+------------------+------+----------+----------+-------------------+-------------
public | varbitmultirange | varbitmultirange | var | | postgres | |
public | varbitrange | varbitrange | var | | postgres | |
(2 rows)

d=# create user joe;
CREATE ROLE
d=# alter type varbitrange owner to joe;
ALTER TYPE
d=# \dT+
List of data types
Schema | Name | Internal name | Size | Elements | Owner | Access privileges | Description
--------+------------------+------------------+------+----------+----------+-------------------+-------------
public | varbitmultirange | varbitmultirange | var | | postgres | |
public | varbitrange | varbitrange | var | | joe | |
(2 rows)

That's pretty broken, isn't it? joe would own the multirange if he'd
created the range to start with. Even if you think the ownerships
ideally should be separable, this behavior causes existing pg_dump
files to restore incorrectly, because pg_dump assumes it need not emit
any commands about the multirange.

A related issue is that you can manually alter the multirange's
ownership:

d=# alter type varbitmultirange owner to joe;
ALTER TYPE

which while it has some value in allowing recovery from this bug,
is inconsistent with our handling of other dependent types such
as arrays:

d=# alter type _varbitrange owner to joe;
ERROR: cannot alter array type varbitrange[]
HINT: You can alter type varbitrange, which will alter the array type as well.

Possibly the thing to do about that is to forbid it in HEAD
for consistency, while still allowing it in back branches
so that people can clean up inconsistent ownership if needed.

regards, tom lane