Re: unnesting multirange data types

On Mon, Jun 21, 2021 at 1:24 AM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> On Sun, Jun 20, 2021 at 11:09 AM Noah Misch <noah(at)leadboat(dot)com> wrote:
> > On Sat, Jun 19, 2021 at 10:05:09PM -0400, Tom Lane wrote:
> > > Alexander Korotkov <aekorotkov(at)gmail(dot)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.
>
> FWIW, there is a patch implementing just unnest() function.

BTW, I found some small inconsistencies in the declaration of
multirange operators in the system catalog. Nothing critical, but if
we decide to bump catversion in beta3, this patch is also nice to
push.

------
Regards,
Alexander Korotkov