On 11/21/19 1:06 AM, Pavel Stehule wrote: > 2. I don't like introduction "safe" operators - now the basic operators > are doubled, and nobody without documentation will use @* operators. > > It is not intuitive. I think is better to map this functionality to > basic operators +- * and implement it just for pairs (Multirange, > Multirange) and (Multirange, Range) if it is possible > > It's same relation line Numeric X integer. There should not be > introduced new operators. If somebody need it for ranges, then he can > use cast to multirange, and can continue. > [snip] > 3. There are not prepared casts - > > postgres=# select int8range(10,15)::int8multirange; > ERROR: cannot cast type int8range to int8multirange > LINE 1: select int8range(10,15)::int8multirange; > ^ > There should be some a) fully generic solution, or b) possibility to > build implicit cast when any multirange type is created.
Okay, I like the idea of just having `range + range` and `multirange + multirange`, then letting you cast between ranges and multiranges. The analogy to int/numeric seems strong. I guess if you cast a multirange with more than one element to a range it will raise an error. That will let me clean up the docs a lot too.
I though about it, and I think so cast from multirange to range is useless, minimally it should be explicit.
On second hand - from range to multirange should be implicit.
The original patch did
1. MR @x MR = MR
2. R @x R = MR
3. MR @x R = MR
I think so @1 & @3 has sense, but without introduction of special operator. @2 is bad and can be solved by cast one or second operand.
