From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: pgsql-hackers@lists.postgresql.org
Subject: Re: ALTER TYPE OWNER fails to recurse to multirange
In-reply-to: <CA+Tgmob2Ku6Mnk=4Z8iLqNXra8NmX+t9EmED5Hy+DZR+81UqUQ@mail.gmail.com>
References: <1580383.1705343264@sss.pgh.pa.us> <CA+TgmoZZFj_XQi9_nJ7f-6jQk=-m+Ki9RTAehBWf9E21bVmS+Q@mail.gmail.com> <1587577.1705346911@sss.pgh.pa.us> <CA+Tgmob2Ku6Mnk=4Z8iLqNXra8NmX+t9EmED5Hy+DZR+81UqUQ@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Mon, 15 Jan 2024 15:01:25 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <1737413.1705423605.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Tue, 16 Jan 2024 11:46:45 -0500
Message-ID: <1737414.1705423605@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/1737414.1705423605%40sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jan 15, 2024 at 2:28 PM Tom Lane <tgl@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