On Sat, 7 Mar 2020 at 16:27, Pavel Stehule <pavel.steh...@gmail.com> wrote:
> > so 7. 3. 2020 v 22:20 odesílatel Tom Lane <t...@sss.pgh.pa.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.