vlsi commented on code in PR #5297:
URL: https://github.com/apache/calcite/pull/5297#discussion_r4210236513
##########
site/_docs/reference.md:
##########
@@ -1828,6 +1828,18 @@ i: implicit cast / e: explicit cast / x: not allowed
make `1 = true` and `0 = false` always evaluate to `TRUE`;
if there is numeric type operand, find common type for both operands;
if operands are `UUID` and `CHARACTER` or `BINARY`, promote to `UUID`.
+ By default, comparing `DECIMAL` with `REAL` narrows to the
+ approximate type (`REAL` has 24-bit mantissa, about 7 decimal digits),
+ so distinct values can compare as equal. The same applies to `BETWEEN`,
+ `IN`, quantified comparisons, `NATURAL JOIN`, and `JOIN USING`, and to
+ the element types of `ARRAY`, `MAP`, and `ROW`. (`CASE`, `COALESCE`,
+ and set operations are not affected: they already use `DOUBLE` for this
+ combination.) To widen to `DOUBLE` instead, override
+ `TypeCoercion#commonTypeForBinaryComparison` in a `TypeCoercionImpl`
+ subclass and install it via
+ `SqlValidator.Config#withTypeCoercionFactory`. This opt-in is available
+ to applications using `Frameworks` or `SqlValidatorUtil`; there is no
+ JDBC connection property for it.
Review Comment:
`DOUBLE` holds about 15 significant digits, and the paragraph no longer says
so: the caveat went away with the `TypeCoercion` javadoc I asked you to trim.
Suggested:
```suggestion
JDBC connection property for it. `DOUBLE` has a 53-bit mantissa, about
15 decimal digits, so `DECIMAL` values with more significant digits can
still compare as equal after widening.
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
