Re: range_agg
От | Isaac Morland |
---|---|
Тема | Re: range_agg |
Дата | |
Msg-id | CAMsGm5eifbmOaD-N5-UTY3FYa_uM0ZHDonE4TqqjEVAzYLYUKA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: range_agg (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: range_agg
|
Список | pgsql-hackers |
On Sat, 7 Mar 2020 at 16:27, Pavel Stehule <pavel.stehule@gmail.com> wrote:
so 7. 3. 2020 v 22:20 odesílatel Tom Lane <tgl@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 doselect '[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.
В списке pgsql-hackers по дате отправления: