Description
The COVERAGE operator requires a FROM clause that references a table or named CTE by name. Inline subqueries (FROM (SELECT ...) AS sub) and VALUES clauses currently raise a ValueError at transpile time:
COVERAGE requires a FROM clause that references a table or CTE by name. Inline subqueries and VALUES clauses in FROM are not yet supported — wrap the derivation in a WITH clause (CTE) and select COVERAGE(...) from the CTE by name instead.
Extend CoverageTransformer._transform_for_coverage in src/giql/transformer.py so the transformer accepts exp.Subquery and exp.Values FROM expressions: preserve the expression in both the __giql_chroms subquery and the LEFT JOIN instead of referencing a bare table name. Decide on a column-mapping story for subqueries — either require the subquery to project the default chrom/start/end columns, or add an optional schema parameter callers can pass alongside the query.
Regression coverage: the intentionally-failing test in tests/unit/test_transformer.py that today asserts the ValueError should flip to a passing test, plus add a DuckDB end-to-end test that runs COVERAGE over an inline subquery.
Motivation
Users can work around the limitation by wrapping the derivation in a WITH clause, and the CTE-preservation fix landed in PR #62 (commit 23205ed) ensures the workaround composes correctly with the internal __giql_bins CTE. So every inline-subquery query already has a trivial equivalent, and this feature is pure ergonomics — no missing capability.
Priority is low. The docs at docs/dialect/aggregation-operators.rst under "Supported FROM clauses" already point users at the working CTE pattern.
Expected outcome
A query like
SELECT COVERAGE(interval, 1000) FROM (SELECT * FROM features WHERE score > 50) AS sub
transpiles and executes against DuckDB and PostgreSQL, producing the same results as the CTE-wrapped equivalent.
Related: PR #62 findings B1.5 (raise on non-table FROM) and B5.2 (CTE preservation).
Description
The
COVERAGEoperator requires aFROMclause that references a table or named CTE by name. Inline subqueries (FROM (SELECT ...) AS sub) andVALUESclauses currently raise aValueErrorat transpile time:Extend
CoverageTransformer._transform_for_coverageinsrc/giql/transformer.pyso the transformer acceptsexp.Subqueryandexp.ValuesFROM expressions: preserve the expression in both the__giql_chromssubquery and theLEFT JOINinstead of referencing a bare table name. Decide on a column-mapping story for subqueries — either require the subquery to project the defaultchrom/start/endcolumns, or add an optional schema parameter callers can pass alongside the query.Regression coverage: the intentionally-failing test in
tests/unit/test_transformer.pythat today asserts the ValueError should flip to a passing test, plus add a DuckDB end-to-end test that runsCOVERAGEover an inline subquery.Motivation
Users can work around the limitation by wrapping the derivation in a
WITHclause, and the CTE-preservation fix landed in PR #62 (commit23205ed) ensures the workaround composes correctly with the internal__giql_binsCTE. So every inline-subquery query already has a trivial equivalent, and this feature is pure ergonomics — no missing capability.Priority is low. The docs at
docs/dialect/aggregation-operators.rstunder "Supported FROM clauses" already point users at the working CTE pattern.Expected outcome
A query like
transpiles and executes against DuckDB and PostgreSQL, producing the same results as the CTE-wrapped equivalent.
Related: PR #62 findings B1.5 (raise on non-table FROM) and B5.2 (CTE preservation).