New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Different returned datatype of a CASE
statement in different query.
#7064
Comments
Hmm it looks like the CASE statement in the second one doesn't get optimized properly. SELECT t0.c0 FROM t0 WHERE (
(
t0.c0
) NOT LIKE(
SELECT t0.c0 FROM t0
)
); Which does produce the right result
|
Manually reduced version physical plan: ┌─────────────────────────────┐
│┌───────────────────────────┐│
││ Physical Plan ││
│└───────────────────────────┘│
└─────────────────────────────┘
┌───────────────────────────┐
│ PROJECTION │
│ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │
│ c0 │
└─────────────┬─────────────┘
┌─────────────┴─────────────┐
│ BLOCKWISE_NL_JOIN │
│ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │
│ INNER ├──────────────┐
│ (CAST(c0 AS VARCHAR) !~~ │ │
│ CAST(SUBQUERY AS VARCHAR))│ │
└─────────────┬─────────────┘ │
┌─────────────┴─────────────┐┌─────────────┴─────────────┐
│ SEQ_SCAN ││ UNGROUPED_AGGREGATE │
│ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ││ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │
│ t0 ││ first(#0) │
│ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ││ │
│ c0 ││ │
│ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ││ │
│ EC: 0 ││ │
└───────────────────────────┘└─────────────┬─────────────┘
┌─────────────┴─────────────┐
│ PROJECTION │
│ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │
│ #0 │
└─────────────┬─────────────┘
┌─────────────┴─────────────┐
│ LIMIT │
└─────────────┬─────────────┘
┌─────────────┴─────────────┐
│ SEQ_SCAN │
│ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │
│ t0 │
│ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │
│ c0 │
│ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │
│ EC: 0 │
└───────────────────────────┘ Original (second query) physical plan: ┌─────────────────────────────┐
│┌───────────────────────────┐│
││ Physical Plan ││
│└───────────────────────────┘│
└─────────────────────────────┘
┌───────────────────────────┐
│ PROJECTION │
│ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │
│ c0 │
└─────────────┬─────────────┘
┌─────────────┴─────────────┐
│ BLOCKWISE_NL_JOIN │
│ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │
│ INNER │
│(CAST(CAST(c0 AS TIMESTAMP)├──────────────┐
│ AS VARCHAR) !~~ CAST │ │
│ (SUBQUERY AS VARCHAR)) │ │
└─────────────┬─────────────┘ │
┌─────────────┴─────────────┐┌─────────────┴─────────────┐
│ SEQ_SCAN ││ UNGROUPED_AGGREGATE │
│ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ││ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │
│ t0 ││ first(#0) │
│ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ││ │
│ c0 ││ │
│ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ││ │
│ EC: 0 ││ │
└───────────────────────────┘└─────────────┬─────────────┘
┌─────────────┴─────────────┐
│ PROJECTION │
│ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │
│ #0 │
└─────────────┬─────────────┘
┌─────────────┴─────────────┐
│ LIMIT │
└─────────────┬─────────────┘
┌─────────────┴─────────────┐
│ SEQ_SCAN │
│ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │
│ t0 │
│ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │
│ c0 │
│ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │
│ EC: 0 │
└───────────────────────────┘ |
I got it! Thank you very much for such a quick reply. |
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days. |
This issue was closed because it has been stale for 30 days with no activity. |
What happens?
Consider the following program:
DuckDB produces the following results:
As there is only one row in
t0
, so the second query is equivalent to the first one. But they have different results.Then I tried this query
SELECT CASE (1) WHEN (2) THEN (TIMESTAMP '1969-12-21 06:13:06') ELSE t0.c0 END FROM t0;
and got this result:means the
DATA
value was cast to aTIMESTAMP
value.And for this query
SELECT t0.c0 FROM t0 WHERE (((CASE (1) WHEN (2) THEN (TIMESTAMP '1969-12-21 06:13:06') ELSE t0.c0 END )) == ((DATE '1969-12-10')));
, I got the results:Shoule this
CASE
statement produce a consistent result?To Reproduce
I build DuckDB from source code (d8b4c83), and run this program with CLI.
OS:
ubuntu 22.04
DuckDB Version:
commit version d8b4c83
DuckDB Client:
CLI
Full Name:
Chi Zhang
Affiliation:
Nanjing University, National University of Singapore
Have you tried this on the latest
master
branch?Have you tried the steps to reproduce? Do they include all relevant data and configuration? Does the issue you report still appear there?
The text was updated successfully, but these errors were encountered: