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

From Alvaro Herrera
Subject Re: unnesting multirange data types
Date
Msg-id 202107151529.crpfydqzdc2l@alvherre.pgsql
Whole thread Raw
In response to Re: unnesting multirange data types  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: unnesting multirange data types  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2021-Jun-19, Tom Lane wrote:

> Alexander Korotkov <aekorotkov@gmail.com> writes:
> > I also don't feel comfortable hurrying with unnest part to beta2.
> > According to the open items wiki page, there should be beta3.  Does
> > unnest part have a chance for beta3?
> 
> Hm.  I'd prefer to avoid another forced initdb after beta2.  On the
> other hand, it's entirely likely that there will be some other thing
> that forces that; in which case there'd be no reason not to push in
> the unnest feature as well.
> 
> I'd say let's sit on the unnest code for a little bit and see what
> happens.

... So, almost a month has gone by, and we still don't have multirange
unnest().  Looking at the open items list, it doesn't look like we have
anything that would require a catversion bump.  Does that mean that
we're going to ship pg14 without multirange unnest?

That seems pretty sad, as the usability of the feature is greatly
reduced.  Just look at what's being suggested:
  https://postgr.es/m/20210715121508.GA30348@depesz.com
To me this screams of an incomplete datatype.  I far prefer a beta3
initdb than shipping 14GA without multirange unnest.

I haven't seen any announcements about beta3, but it's probably not far
off; I think if we're going to have it, it would be much better to give
it buildfarm cycles several days in advance and not just the last
weekend.

What do others think?

-- 
Álvaro Herrera           39°49'30"S 73°17'W  —  https://www.EnterpriseDB.com/
"Ninguna manada de bestias tiene una voz tan horrible como la humana" (Orual)



pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: pg_upgrade does not upgrade pg_stat_statements properly
Next
From: Fujii Masao
Date:
Subject: Re: Transactions involving multiple postgres foreign servers, take 2