[LucaCappelletti94]

SELECT e FROM jsonb_array_elements_text('["a","b"]'::jsonb) AS e answers a, b on PostgreSQL 18.6 and no such column: e after translation. PostgreSQL reads a bare name that no column answers as the whole row of the relation it names, and the row of a one-column function is its value. The derived table pg2sqlite builds over json_each exposes only value, so SQLite found nothing called e. The keys functions had a second problem. PostgreSQL names their one column after the alias, and the projection named it json_object_keys.

A bare name that no column in scope answers, and that names a set-returning JSON function's relation, reads that function's column, and the output keeps the alias as its name. The value functions keep their declared value column, so e.value and value resolve and e.e fails as it does in PostgreSQL. The row of a two-column function such as jsonb_each is a record, which SQLite has no value for, so a bare reference to it is refused naming the alias. A column called e wins over the row, at the same level or an enclosing one, matching PostgreSQL. A SELECT inside a UNION resolves against the same scope as a standalone one, which the set-operation case needed.

The same commit drops an unused ToOwned import that only the no-std build warned about, and makes the no_std (wasm32) job deny warnings so the next one fails CI.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!