From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: ALTER TYPE OWNER fails to recurse to multirange |
Date: | 2024-01-16 16:46:45 |
Message-ID: | 1737414.1705423605@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Jan 15, 2024 at 2:28 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Sergey Prokhorenko | 2024-01-16 16:49:13 | Re: UUID v7 |
Previous Message | Tom Lane | 2024-01-16 16:34:42 | Re: "ERROR: could not open relation with OID 16391" error was encountered when reindexing |