Inconsistent results when casting `BIT` and `VARBINARY`

[suyZhong]

What happens?

Consider the following test case generated by my fuzzer. The second query and the third query could have inconsistent results. I suppose the second query should be consistently true,true and the third query should thus be ab,cd.

To Reproduce

CREATE TABLE  t1(c0 VARBINARY NOT NULL);
INSERT INTO t1(c0) VALUES ('ab'), ('cd');
-- INSERT INTO t1(c0) VALUES ('🦆'); -- error
-- INSERT INTO t1(c0) VALUES (NULL); -- error

SELECT t1.c0 FROM t1; -- 'ab', 'cd'
SELECT ((CAST(CAST(t1.c0 AS BIT) AS VARBINARY))<=(t1.c0)) FROM t1; -- true, true (incosistent, could sometimes be false, false)
SELECT t1.c0 FROM t1 WHERE ((CAST(CAST(t1.c0 AS BIT) AS VARBINARY))<=(t1.c0));
-- Expected: 'ab', 'cd' (2 rows)
-- Actual: could be 0 row, 1 row or 2 rows

Not sure if the two INSERT are needed. Sometimes I could also reproduce it without executing them, but sometimes can't.

Kindly inform me if it's an expected behavior and whether you could reproduce the issue.

OS:

ubuntu 22.04

DuckDB Version:

v1.1.1-dev100 9af117f

DuckDB Client:

CLI

Hardware:

No response

Full Name:

Suyang Zhong

Affiliation:

NUS

What is the latest build you tested with? If possible, we recommend testing with the latest nightly build.

I have tested with a source build

Did you include all relevant data sets for reproducing the issue?

Yes

Did you include all code required to reproduce the issue?

• Yes, I have

Did you include all relevant configuration (e.g., CPU architecture, Python version, Linux distribution) to reproduce the issue?

• Yes, I have

[Tishj]

The use of VARBINARY confused me a bit, BLOB is more commonly used for this type
Also col::BIT can be used in place of CAST(col AS BIT) to make this easier to read, especially with multiple casts taking place