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

From Noah Misch
Subject Re: unnesting multirange data types
Date
Msg-id 20210620080921.GB1285871@rfd.leadboat.com
Whole thread Raw
In response to Re: unnesting multirange data types  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: unnesting multirange data types  (Alexander Korotkov <aekorotkov@gmail.com>)
List pgsql-hackers
On Sat, Jun 19, 2021 at 10:05:09PM -0400, 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.

I think $SUBJECT can't simultaneously offer too little to justify its own
catversion bump and also offer enough to bypass feature freeze.  If multirange
is good without $SUBJECT, then $SUBJECT should wait for v15.  Otherwise, the
matter of the catversion bump should not delay commit of $SUBJECT.



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: pgbench logging broken by time logic changes
Next
From: Fabien COELHO
Date:
Subject: Re: pgbench logging broken by time logic changes