On Tue, Jul 9, 2019 at 12:24 PM Pavel Stehule <pavel.steh...@gmail.com> wrote: > út 9. 7. 2019 v 21:10 odesílatel Pavel Stehule <pavel.steh...@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. Yours, Paul
