On Tue, Jul 9, 2019 at 12:24 PM Pavel Stehule <pavel.stehule@gmail.com> wrote: > út 9. 7. 2019 v 21:10 odesílatel Pavel Stehule <pavel.stehule@gmail.com> napsal: >> 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.
Well I'm afraid of that too a bit, although I also agree it may be an opportunity to share some common behavior and implementation. For example in the discussion about string syntax, I think keeping it the same as arrays is nicer for people and lets us share more between the two types.
That said I don't think a multirange is a subtype of arrays (speaking as a traditional object-oriented subtype), just something that shares a lot of the same behavior. I'm inclined to maximize the overlap where feasible though, e.g. string syntax, UNNEST, indexing, function naming (`range_length`), etc. Something like Rust traits (or Java interfaces) seems a closer mental model, not that we have to formalize that somehow, particularly up front.
A introduction of new generic type can have some other impacts - there can be necessary special support for PL languages.
I understand so it is hard to decide - because we miss some more generic base "sets".
Probably we cannot to think more about it now, and we have to wait to some patches. Later we can see how much code is duplicated and if it is a problem or not.
