Robert Haas <robertmh...@gmail.com> writes: > On Mon, Jan 15, 2024 at 2:28 PM Tom Lane <t...@sss.pgh.pa.us> wrote: >> I'm reasoning by analogy to array types, which are automatically >> created and automatically updated to keep the same ownership >> etc. properties as their base type. To the extent that multirange >> types don't act exactly like that, I say it's a bug/oversight in the >> multirange patch. So I think this is a backend bug, not a pg_dump >> bug.
> Well, I guess maybe I'm just clueless. I thought that the range and > multirange were two essentially independent objects being created by > the same command. But I haven't studied the implementation so maybe > I'm completely wrong. They're by no means independent. What would it mean to have a multirange without the underlying range type? Also, we already treat the multirange as dependent for some things: d=# create type varbitrange as range (subtype = varbit); CREATE TYPE d=# \dT List of data types Schema | Name | Description --------+------------------+------------- public | varbitmultirange | public | varbitrange | (2 rows) d=# drop type varbitmultirange; ERROR: cannot drop type varbitmultirange because type varbitrange requires it HINT: You can drop type varbitrange instead. d=# drop type varbitrange restrict; DROP TYPE d=# \dT List of data types Schema | Name | Description --------+------+------------- (0 rows) So I think we're looking at a half-baked dependency design, not two independent objects. regards, tom lane