From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com> |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: range_agg |
Date: | 2019-07-09 19:02:38 |
Message-ID: | 6661d30898f776e1b5a6bf2c84509c6b2f36552c.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Paul Jungwirth | 2019-07-09 19:05:16 | Re: range_agg |
Previous Message | Alvaro Herrera | 2019-07-09 19:01:18 | Re: range_agg |