Re: range_agg

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: range_agg
Date: 2019-07-10 04:50:23
Message-ID: CAFj8pRDYe0sDpLLcHWKoEn-vpUSxJvj-5puPttbpYODSS5Ev6w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

st 10. 7. 2019 v 6:26 odesílatel Paul A Jungwirth <
pj(at)illuminatedcomputing(dot)com> napsal:

> On Tue, Jul 9, 2019 at 12:24 PM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> > út 9. 7. 2019 v 21:10 odesílatel Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> napsal:
> >> I afraid so with generic multiragetype there lot of array
> infrastructure will be duplicated
> >
> > on second hand - it is true so classic array concat is not optimal for
> set of ranges, so some functionality should be redefined every time.
> >
> > I don't know what is possible, but for me - multiranges is special kind
> (subset) of arrays and can be implement as subset of arrays. I remember
> other possible kind of arrays - "sets" without duplicates. It is similar
> case, I think.
> >
> > Maybe introduction of multirages as new generic type is bad direction,
> and can be better and more enhanceable in future to introduce some like
> special kinds of arrays. So for example - unnest can be used directly for
> arrays and multiranges too - because there will be common base.
>
> Well I'm afraid of that too a bit, although I also agree it may be an
> opportunity to share some common behavior and implementation. For
> example in the discussion about string syntax, I think keeping it the
> same as arrays is nicer for people and lets us share more between the
> two types.
>
> That said I don't think a multirange is a subtype of arrays (speaking
> as a traditional object-oriented subtype), just something that shares
> a lot of the same behavior. I'm inclined to maximize the overlap where
> feasible though, e.g. string syntax, UNNEST, indexing, function naming
> (`range_length`), etc. Something like Rust traits (or Java interfaces)
> seems a closer mental model, not that we have to formalize that
> somehow, particularly up front.
>

A introduction of new generic type can have some other impacts - there can
be necessary special support for PL languages.

I understand so it is hard to decide - because we miss some more generic
base "sets".

Probably we cannot to think more about it now, and we have to wait to some
patches. Later we can see how much code is duplicated and if it is a
problem or not.

Regards

Pavel

> Yours,
> Paul
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2019-07-10 04:58:26 Re: SQL/JSON path issues/questions
Previous Message Michael Paquier 2019-07-10 04:46:18 Re: Add parallelism and glibc dependent only options to reindexdb