Re: range_agg

Hi

út 2. 7. 2019 v 0:38 odesílatel Jeff Davis <pgsql(at)j-davis(dot)com> napsal:

> On Fri, 2019-05-03 at 15:56 -0700, Paul Jungwirth wrote:
> > Hello,
> >
> > I wrote an extension to add a range_agg function with similar
> > behavior
> > to existing *_agg functions, and I'm wondering if folks would like
> > to
> > have it in core? Here is the repo:
> > https://github.com/pjungwir/range_agg
>
> This seems like a very useful extension, thank you.
>
> For getting into core though, it should be a more complete set of
> related operations. The patch is implicitly introducing the concept of
> a "multirange" (in this case, an array of ranges), but it's not making
> the concept whole.
>
> What else should return a multirange? This patch implements the union-
> agg of ranges, but we also might want an intersection-agg of ranges
> (that is, the set of ranges that are subranges of every input). Given
> that there are other options here, the name "range_agg" is too generic
> to mean union-agg specifically.
>
> What can we do with a multirange? A lot of range operators still make
> sense, like "contains" or "overlaps"; but "adjacent" doesn't quite
> work. What about new operations like inverting a multirange to get the
> gaps?
>
> Do we want to continue with the array-of-ranges implementation of a
> multirange, or do we want a first-class multirange concept that might
> eliminate the boilerplate around defining all of these operations?
>
> If we have a more complete set of operators here, the flags for
> handling overlapping ranges and gaps will be unnecessary.
>

I think so scope of this patch is correct. Introduction of set of ranges
data type based on a array or not, should be different topic.

The question is naming - should be this agg function named "range_agg", and
multi range agg "multirange_agg"? Personally, I have not a problem with
range_agg, and I have not a problem so it is based on union operation. It
is true so only result of union can be implemented as range simply. When I
though about multi range result, then there are really large set of
possible algorithms how to do some operations over two, three values. So
personally, I am satisfied with scope of simple range_agg functions,
because I see a benefits, and I don't think so this implementation block
any more complex designs in the future. There is really big questions how
to implement multi range, and now I think so special data type will be
better than possible unordered arrays.

Regards

Pavel

Regards,
> Jeff Davis
>
>
>
>
>