Re: range_agg

út 9. 7. 2019 v 21:10 odesílatel Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
napsal:

>
>
> út 9. 7. 2019 v 20:25 odesílatel Jeff Davis <pgsql(at)j-davis(dot)com> napsal:
>
>> On Tue, 2019-07-09 at 07:08 +0200, Pavel Stehule wrote:
>> >
>> > I am not against a multirange type, but I miss a explanation why you
>> > introduce new kind of types and don't use just array of ranges.
>> >
>> > Introduction of new kind of types is not like introduction new type.
>>
>> The biggest benefit, in my opinion, is that it means you can define
>> functions/operators that take an "anyrange" and return an
>> "anymultirange". That way you don't have to define different functions
>> for int4 ranges, date ranges, etc.
>>
>>
> I am not sure how strong is this argument.
>
> I think so introduction of anyrangearray polymorphic type and enhancing
> some type deduction can do same work.
>
> It starts to get even more complex when you want to add opclasses, etc.
>>
>> Ranges and arrays are effectively generic types that need a type
>> parameter to become a concrete type. Ideally, we'd have first-class
>> support for generic types, but I think that's a different topic ;-)
>
>
> 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.

Regards

Pavel

> Regards
>
> Pavel
>
>
>> Regards,
>> Jeff Davis
>>
>>
>>