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

From Jonathan S. Katz
Subject Re: unnesting multirange data types
Date
Msg-id 43916655-ccb0-f132-a292-67927a7a3ab3@postgresql.org
Whole thread Raw
In response to Re: unnesting multirange data types  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: unnesting multirange data types  ("Jonathan S. Katz" <jkatz@postgresql.org>)
List pgsql-hackers
On 6/13/21 7:43 AM, Alexander Korotkov wrote:
> On Sun, Jun 13, 2021 at 2:58 AM Alexander Korotkov <aekorotkov@gmail.com> wrote:
>> On Sun, Jun 13, 2021 at 1:16 AM Jonathan S. Katz <jkatz@postgresql.org> wrote:

>>> Again, I'll defer to others on the code, but this seems to solve the use
>>> case I presented. Thanks for the quick turnaround!
>>
>> Thank you for the feedback!
>
> I've added the commit message to the patch.  I'm going to push it if
> no objections.

I went ahead and tried testing a few more cases with the patch, and
everything seems to work as expected.

I did skim through the code -- I'm much less familiar with this part of
the system -- and I did not see anything that I would consider "obvious
to correct" from my perspective.

So I will continue to go with what I said above: no objections on the
use case perspective, but I defer to others on the code.

One question: if I were to make a custom multirange type (e.g. let's say
I use "inet" to make "inetrange" and then a "inetmultirange") will this
method still work? It seems so, but I wanted clarify.

Thanks,

Jonathan


Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: An out-of-date comment in nodeIndexonlyscan.c
Next
From: "Jonathan S. Katz"
Date:
Subject: Re: unnesting multirange data types