Repository navigation
Single column returned on "SELECT *" when named type is present #7468
Description
Two things stand out about this result:
- Only
aappears in the output - Since it's a pure SQL query, I'm guessing there should be
nullinstead oferror
$ super -version &&
super -f bsup -o t2.bsup -c "type foo={a:int64} values cast({a:1},foo), {b:2}" &&
super -c "SELECT * FROM 't2.bsup'"
Version: v0.3.0-508-g4e032a368
{a:1}
{a:error("no such field a")}
Details
Repro is with super commit 4e032a3.
Without the named type, the output shows both columns.
$ super -f bsup -o t2.bsup -c "values {a:1}, {b:2}" &&
super -c "SELECT * FROM 't2.bsup'"
{a:1,b:error("no such field b")}
{a:error("no such field a"),b:2}
With equivalent data/query, on legacy SQL systems null values are present where super put the error values above, so that seems like that may be the thing to do for SQL compatibility reasons.
$ printf '{"a":1}\n{"b":2}\n' > top.json &&
duckdb --version && duckdb -c "SELECT * FROM 'top.json'"
v1.5.6 (Variegata) 069cc9f9b5
┌───────┬───────┐
│ a │ b │
│ int64 │ int64 │
├───────┼───────┤
│ 1 │ NULL │
│ NULL │ 2 │
└───────┴───────┘
$ clickhouse --version &&
clickhouse local --output-format PrettyCompact -q "SELECT * FROM file('top.json')"
ClickHouse local version 26.9.15.5 (official build).
┌────a─┬────b─┐
1. │ 1 │ ᴺᵁᴸᴸ │
2. │ ᴺᵁᴸᴸ │ 2 │
└──────┴──────┘
Activity
philrz commentedon Oct 13, 2026
Here's an additional finding RE:
errorvs.nullthat may be related or may need its own issue: The same records give the expected-with-SQL-querynullif the BSUP file is written from JSON instead of withvaluesas it was done above. Starting with thet2.bsupproduced in the repro above:fix bug with projected missing under nullish
fix bug with projected missing under nullish (#7548)
philrz commentedon Oct 28, 2026
As of commit 2541a5e, the second of the two symptoms shown above has been addressed by linked PR #7548:
nullvalues now appear in the output of the pure SQL query instead oferrorvalues.However, for the first symptom above RE: when the named type is present, the SQL query still only returns the
avalues.So while #7548 notes that "the named type didn't turn out to be the problem", something still seems amiss, so I'll check with @mccanne.