On Sat, 2020-03-07 at 16:06 -0500, Tom Lane wrote:
> Actually ... have you given any thought to just deciding that ranges
> and
> multiranges are the same type?
It has come up in a number of conversations, but I'm not sure if it was
discussed on this list.
> I think on the whole the advantages win,
> and I feel like that might also be the case here.
Some things to think about:
1. Ranges are common -- at least implicitly -- in a lot of
applications/systems. It's pretty easy to represent extrernal data as
ranges in postgres, and also to represent postgres ranges in external
systems. But I can see multiranges causing friction around a lot of
common tasks, like displaying in a UI. If you only expect ranges, you
can add a CHECK constraint, so this is annoying but not necessarily a
deal-breaker.
2. There are existing client libraries[1] that support range types and
transform them to types within the host language. Obviously, those
would need to be updated to expect multiple ranges.
3. It seems like we would want some kind of base "range" type. When you
try to break a multirange down into constituent ranges, what type would
those pieces be? (Aside: how do you get the constituent ranges?)
I'm thinking more about casting to see if there's a possible compromise
there.
Regards,
Jeff Davis
[1]
https://sfackler.github.io/rust-postgres-range/doc/v0.8.2/postgres_range/