[Bug]: arithmetic predicate transposition changes floating results and hides integer overflow #29542

Is there an existing issue for the same bug?

• I checked existing issues (ConstantTranspose, transpose, floating arithmetic filter, floating point wrong result).

Branch Name

main

Commit ID

7b3d0c3

Other Environment Information

Linux amd64, CPU build, Go 1.26.4. Local isolated CN/TN/logservice with MinIO, GOMAXPROCS=2. Reproduced on actual SQL execution, not only plan inspection.

Actual Behavior

The planner algebraically transposes top-level arithmetic equality without proving preservation of floating rounding or integer overflow behavior. This produces incorrect rows and suppresses an arithmetic error. A logically equivalent OR wrapper uses the guarded Boolean normalization and gives different results.

Steps to Reproduce

CREATE DATABASE qa_transpose;
USE qa_transpose;
CREATE TABLE fp(v DOUBLE);
INSERT INTO fp VALUES (1e-17), (0), (NULL);
SELECT v, v + 1e0 = 1e0 FROM fp ORDER BY v;
-- NULL NULL; 0 true; 0.00000000000000001 true
SELECT v FROM fp WHERE v + 1e0 = 1e0 ORDER BY v;
-- Actual: only 0. Expected: 0 and 0.00000000000000001.
SELECT v FROM fp WHERE v + 1e0 = 1e0 OR v IS NULL ORDER BY v;
-- Actual: all three rows, including 1e-17.
EXPLAIN SELECT v FROM fp WHERE v + 1e0 = 1e0;
-- Filter Cond: (fp.v = 0)

CREATE TABLE ov(v BIGINT);
INSERT INTO ov VALUES (9223372036854775807);
SELECT v FROM ov WHERE v + 1 = 9223372036854775807;
-- Actual: empty result, no error.
SELECT v, v + 1 FROM ov;
-- ERROR 1690 (22003): int64 out of range (9223372036854775807 + 1).

Expected Behavior

Filter evaluation must preserve SQL arithmetic semantics. For binary64, 1e-17 + 1 rounds to 1, so transposing this equality to v=0 is invalid. Integer overflow must not disappear because a predicate is algebraically rearranged.

Additional Information

pkg/sql/plan/utils.go:ConstantTranspose still performs legacy equality algebra using canTranspose/getPath and inverse +/- operations. normalizeNativeRangeDirection protects Boolean subtrees, but top-level equality falls through to the old transformation. The existing planner normalization should own a consistent arithmetic safety policy across both paths; avoid a separate competing rewrite or merely patching this literal example.

Found during integrated QA of the latest ten author commits, including #29525. Attribution is not part of this report. The new Boolean guard does not close the shared top-level arithmetic domain invariant.

Suggested regression coverage: DOUBLE/FLOAT absorbed increments, cancellation and subtraction direction, prepared bindings, AND/OR nesting, integer overflow/underflow, safe exact controls, and indexed/composite-sortkey filters. Compare actual row sets and error behavior to independently evaluated expressions, not only expected generated plans.