>
> > Current proposal has a "closed" parameter with {left, right, both,
> > neither}. How about we extend that to {left, right, both, neither,
> > left_per_value, right_per_value, both_per_value}?
> > This is similar to proposal 3.
>
> The asymmetric sub-modes are a nice space optimization when only
> one side varies, but my intuition is that this is a rare case. Discrete
> ranges canonicalize on both sides, and continuous ranges typically vary
> on both. Do you have a concrete use-case in mind?
>
I don't have a specific use case. However if we specify the more
general option here, does it increase implementation complexity or runtime
memory requirements? If not I'd rather we specify a more general solution.
> Should we specify closedness information per value as optional?
> > Could null closedness have some meaning?
>
> Do you mean that the storage type should be `Struct<lower: T, upper: T,
> lower_inc: bool (nullable), upper_inc: bool (nullable)>`?
> I guess the meaning would be "closedness is unspecified for this value,
> fall back to the default closedness specified in column-metadata"?
> I would not do that, because this means carrying two extra validity
> bitmaps just to encode a fallback. Copying the default closedness
> into the flags is faster and more memory efficient, as the
> flags stay non-nullable, and uniform columns compress trivially under
> RLE or dictionary encoding.
> Or did I misunderstand your proposal?
>
I like that interpretation. Perhaps we can allow for both nullable and
non-nullable options?
Rok
