Soeren Wolfers

Issue persists on 1.0.0.

There is a difference between columns of type VARCHAR and string literals. See the page https://duckdb.org/docs/sql/data_types/literal_types which is linked to from the site you cited. That being said, it would...

@szarnyasg I'm confused. On the documentation PR, which you merged, I'm stating the UNION ALL is performing implicit casts only. In the issue here, I'm complaining that UNION ALL performs...

But the expected behavior really is that the casting rules in the UNION ALL clause are different from those anywhere else?

Issue still persists on 1.0.0

issue still persists on 1.1 and does not only affect the UNION clause. ```sql SELECT [0, true] ``` works and returns an integer list.

@Tmonster The query plans *should* be equivalent though. They might not be equal, but they should produce equal results; they do in PostgreSQL at least. See https://www.db-fiddle.com/f/4xiYbrbGgbCsbGT4dJzHmB/0 where the two...

The problem with "recommend sticking to CTEs" is that (1) it's hard to know in what situations that recommendation applies (2) CTEs come with their own performance problems (e.g. they...

If this ticket is going to be on the backlog for a while, renaming it to "Unnest in lateral join gives wrong results" (which happens if you just make the...

Update on duckdb v1.1: The parser bug has been solved: The two queries return identical results now for smaller examples. Now a performance bug is left: The "slow" query in...