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