Unexpected Results when Comparing with Bigint

[suyZhong]

Describe the bug

Consider the following test case. It is unexpected that both queries return the row, since the expression -9223372036854775808<=c0 and -9223372036854775808<=c0 IS NULL cannot be evaluated to TRUE at the same time. We could make value larger (let's say 9223372036854775000) I think it's similar to #13497

Error message/log

No response

To Reproduce

CREATE TABLE t0(c0 INT, c1 INT, PRIMARY KEY(c0));
INSERT INTO t0(c1) VALUES (1);

SELECT c1 FROM t0 WHERE -9223372036854775808<=c0;  -- 1
SELECT c1 FROM t0 WHERE -9223372036854775808<=c0 IS NULL; -- 1

Expected behavior

At least one of the two queries returns an empty table.

How did you deploy RisingWave?

via Docker image and online playground

The version of RisingWave

dev=> SELECT VERSION();
                                     version                                      
----------------------------------------------------------------------------------
 PostgreSQL 9.5-RisingWave-1.3.0-alpha (b3eecb3d97471e14b578d2441e6cf8227ac372aa)
(1 row)

Additional context

No response

[yuhao-su]

dev=> explain SELECT c1 FROM t0 WHERE -9223372036854775808<=c0 ;
                QUERY PLAN                 
-------------------------------------------
 BatchExchange { order: [], dist: Single }
 └─BatchScan { table: t0, columns: [c1] }
(2 rows)

The scan range is missing? cc. @chenzl25

[chenzl25]

@ZENOTME PTAL. It seems shrink cast for condition assumes InputRef data type is not Null, however, all our data type is nullable.

[ZENOTME]

The result -9223372036854775808<=null will be treated as null. But the shrink cast will replace -9223372036854775808<=col1 as true. This will miss the null case.

I guess we shouldn't do the shrink cast here. We should push down it to scan and optimize it in scan in central. e.g. For the outbound number, we can treat the cond as false or true if the input is not null. And return null if the input is null.