sql: prepared selects that filter a column with a constant casted to the wrong type fail to return the expected results

[rhu713]

Describe the problem

After upgrading from 21.1.10 to 21.2.7, prepared statements on a table with a DECIMAL primary key do not return the matching rows if the WHERE clause casts the primary key parameter to INT::8. This statement previously worked on a 21.1.10 cluster.

To Reproduce
This small test case on a demo cluster reproduces the issue

root@127.0.0.1:26257/movr> create table t_dec (a decimal not null primary key, b int);
CREATE TABLE


Time: 11ms total (execution 11ms / network 0ms)

root@127.0.0.1:26257/movr>  prepare stmt1 AS SELECT * FROM t_dec WHERE a = $1::INT8;
PREPARE


Time: 8ms total (execution 8ms / network 0ms)

root@127.0.0.1:26257/movr> INSERT INTO t_dec VALUES (1, 100), (2, 200);                                                                       
INSERT 2


Time: 2ms total (execution 1ms / network 0ms)

root@127.0.0.1:26257/movr>  SELECT * FROM t_dec WHERE a = 1;
  a |  b
----+------
  1 | 100
(1 row)


Time: 1ms total (execution 1ms / network 0ms)

root@127.0.0.1:26257/movr>  EXECUTE stmt1 (1);
  a | b
----+----
(0 rows)

Expected behavior
EXECUTE stmt1 (1); is expected to return the (1, 100) row on 21.2. The row is returned if these steps are reproduced on a 21.1 cluster.

Additional data / screenshots

Environment:

• CockroachDB version 21.2.7

Jira issue: CRDB-15244

[rafiss]

We saw this bug in a support case, and captured statement bundles of the working and non-working versions of the query.

In that example, the decimal value was 331, and when using the prepared statement, it was encoded as \367\016\217\212\367\001K\210; when used in a simple query it was \367\016\217\212+\007>\000\210. My understanding from reading reading https://github.com/cockroachdb/cockroach/blob/master/docs/tech-notes/encoding.md#composite-encoding) is that we are supposed to treat these as equivalent, but I’m not too familiar with the details.