Re: unnesting multirange data types

From: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: unnesting multirange data types
Date: 2021-06-09 23:00:24
Message-ID: 95432464-1b63-bc84-6f84-e9e9d79f9687@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 6/9/21 4:56 PM, Alvaro Herrera wrote:
> On 2021-Jun-09, Jonathan S. Katz wrote:
>
>> I did a couple more tests around this.
>>
>> As suspected, in PL/pgSQL, there is no way to unpack or iterate over a
>> multirange type.
>
> Uh. This is disappointing; the need for some way to unnest or unpack a
> multirange was mentioned multiple times in the range_agg thread. I had
> assumed that there was some way to cast the multirange to a range array,
> or somehow convert it, but apparently that doesn't work.

Just to be pedantic with examples:

SELECT datemultirange(
daterange(current_date, current_date + 2),
daterange(current_date + 5, current_date + 7))::daterange[];

ERROR: cannot cast type datemultirange to daterange[]
LINE 1: ...2), daterange(current_date + 5, current_date + 7))::daterang...

IF there was an array to cast it into an array, we could then use the
array looping construct in PL/pgSQL, but if we could only choose one, I
think it'd be more natural/less verbose to have an "unnest".

> If the supporting pieces are mostly there, then I opine we should add
> something.

Agreed.

Jonathan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-06-09 23:09:54 Re: Race condition in recovery?
Previous Message Mark Dilger 2021-06-09 22:50:52 Re: Estimating HugePages Requirements?