Re: unnesting multirange data types - Mailing list pgsql-hackers

From Jonathan S. Katz
Subject Re: unnesting multirange data types
Date
Msg-id b8209c06-88ab-83a4-5b20-455a518d023b@postgresql.org
Whole thread Raw
In response to Re: unnesting multirange data types  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 6/15/21 1:52 PM, Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
>> On 2021-Jun-15, Tom Lane wrote:
>>> I think this ought to be reverted and reviewed more carefully.
>
>> It seems to me that removing the cast-to-range[] is a sufficient fix,
>> and that we can do with only the unnest part for pg14; the casts can be
>> added in 15 (if at all).  That would mean reverting only half the patch.
>
> Might be a reasonable solution.  But right now I'm annoyed that the
> buildfarm is broken, and I'm also convinced that this didn't get
> adequate testing.

I had focused testing primarily on the "unnest" cases that I had
described in my original note. I did a couple of casts and had no issue;
I did not test with pg_dump / pg_upgrade, but noting to do so in the
future in cases like this.

>  I think "revert and reconsider" is the way
> forward for today.

I don't want the buildfarm broken so I'm fine if this is the best way
forward. If we can keep the "unnest" functionality I would strongly
suggest it as that was the premise of the original note to complete the
utility of multiranges for v14. The casting, while convenient, is not
needed.

Jonathan


Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] Fix buffer not null terminated on (ecpg lib)
Next
From: Tom Lane
Date:
Subject: Re: snapshot too old issues, first around wraparound and then more.