On Mon, 2019-07-08 at 09:46 -0700, Paul A Jungwirth wrote:
> - A multirange type is an extra thing you get when you define a range
> (just like how you get a tstzrange[]). Therefore....
Agreed.
> - I'm adding a new typtype for multiranges. ('m' in pg_type).
Sounds reasonable.
> - I'm just adding a mltrngtypeid column to pg_range. I don't think I
> need a new pg_multirange table.
> - You can have a multirange[].
> - Multirange in/out work just like arrays, e.g. '{"[1,3)", "[5,6)"}'
It would be cool to have a better text representation. We could go
simple like:
'[1,3) [5,6)'
Or maybe someone has another idea how to represent a multirange to be
more visually descriptive?
> - I'll add an anymultirange pseudotype. When it's the return type of
> a
> function that has an "anyrange" parameter, it will use the same base
> element type. (So basically anymultirange : anyrange :: anyarray ::
> anyelement.)
I like it.
> - range_agg (range_union_agg if you like)
> - range_intersection_agg
I'm fine with those names.
> - You can subscript a multirange like you do an array (? This could
> be
> a function instead.)
I wouldn't try to hard to make them subscriptable. I'm not opposed to
it, but it's easy enough to cast to an array and then subscript.
> - operators:
> - union (++) and intersection (*):
> - We already have + for range union but it raises an error if
> there is a gap, so ++ is the same but with no errors.
> - r ++ r = mr (commutative, associative)
> - mr ++ r = mr
> - r ++ mr = mr
I like it.
> - inverse operator?:
> - the inverse of {"[1,2)"} would be {"[null, 1)", "[2, null)"}.
> - not sure we want this or what the symbol should be. I don't
> like
> -mr as an inverse because then mr - mr != mr ++ -mr.
I think "complement" might be a better name than "inverse".
m1 - m2 = m1 * complement(m2)
What about "~"?
There will be some changes to parse_coerce.c, just like in range types.
I took a brief look here and it looks pretty reasonable; hopefully
there aren't any hidden surprises.
Regards,
Jeff Davis
