Re: range_agg

On Sat, 7 Mar 2020 at 16:27, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:

>
> so 7. 3. 2020 v 22:20 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:
>
>> I wrote:
>> > Actually ... have you given any thought to just deciding that ranges and
>> > multiranges are the same type? That is, any range can now potentially
>> > contain multiple segments? That would eliminate a whole lot of the
>> > tedious infrastructure hacking involved in this patch, and let you focus
>> > on the actually-useful functionality.
>>
>>

> I think this behave is correct. Sometimes you should to get only one range
> - and this check is a protection against not continuous range.
>
> if you expect multirange, then do
>
> select '[1,2]'::int4range::multirange + '[4,10)'::int4range;
>

Definitely agreed that range and multirange (or whatever it's called)
should be different. In the work I do I have a number of uses for ranges,
but not (yet) for multiranges. I want to be able to declare a column as
range and be sure that it is just a single range, and then call lower() and
upper() on it and be sure to get just one value in each case; and if I
accidentally try to take the union of ranges where the union isn’t another
range, I want to get an error rather than calculate some weird (in my
context) multirange.

On a related note, I was thinking about this and I don’t think I like
range_agg as a name at all. I know we have array_agg and string_agg but
surely shouldn’t this be called union_agg, and shouldn’t there also be an
intersect_agg? I mean, taking the union isn’t the only possible aggregate
on ranges or multiranges.