[kvlonge]

Why

Semantic checks refused DuckDB SQL the engine runs, and missed some errors it refuses:

• LAG(x), LAG(x, n), LEAD(x) and LEAD(x, n) raised E203, because the catalogue listed LAG and LEAD only with three arguments.
• A LATERAL item was checked against every FROM item of its level. A derived table nested in it raised a false E222 for an item to its left, and the LATERAL body could read items to its right, or itself, without an error.
• DuckDB runs a derived table without LATERAL as lateral when it reads an item to its left, but it raised E222.
• A lambda parameter in a grouped SELECT, such as list_filter(ARRAY_AGG(x), lambda e: e <> 'null'), raised E230 as an ungrouped column.

Changes

• The DuckDB catalogue extractor records each argument count DuckDB binds for a window function, which adds LAG and LEAD with one and two arguments.
• Each FROM item records where its sources start. A LATERAL item, and anything nested in it, reads only the items before it, then the enclosing queries, in every dialect.
• Under DuckDB only, a derived table without LATERAL reads the items before it, in name resolution and in lineage.
• The grouping check exempts a lambda's parameters inside its body and still checks outer columns there.

Verification

• New regression tests fail on main and pass here. They go through DuckDB's and PostgreSQL's own parsers, and every verdict was checked on DuckDB 2.0.0 and PostgreSQL 18.6.
• cargo test -p sqlquack-semantics --all-features
• make check-ci
• make verify-recorded: 0 failed, and no other changes.
• Not checked on Snowflake: no engine access was available for this change. Snowflake goes through the same paths and gets the same verdicts.