On Mon, Mar 09, 2020 at 06:34:04PM -0700, Jeff Davis wrote: > 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.
It could become well and truly burdensome in a UI or an API. The difference between one, as ranges are now, and many, as multi-ranges would be if we shoehorn them into the range type, are pretty annoying to deal with. > 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. The type systems that would support such types might get unhappy with us if we started messing with some of the properties like contiguousness. > 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. I think the right compromise is to recognize that the closure of a set (ranges) over an operation (set union) may well be a different set (multi-ranges). Other operations have already been proposed, complete with concrete use cases that could really make PostgreSQL stand out. That we don't have an obvious choice of "most correct" operation over which to close ranges makes it even bigger a potential foot-gun when we choose one arbitrarily and declare it to be the canonical one. Best, David. -- David Fetter <david(at)fetter(dot)org> http://fetter.org/ Phone: +1 415 235 3778 Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
