fix: derive comprehension JSON access from the range, not variable names

[richardwooding]

Why

Two hardcoded name lists survived #193, both in the comprehension path. Removing them leaves none in the converter:

$ grep -rn '\[\]string{"' --include='*.go' . | grep -v _test | grep -v /examples/
$

isJSONObjectFieldAccess — variable names

Field access on a comprehension variable extracted from a JSON document whenever the variable was named attr, item, element, obj, feature or review. Both directions were wrong:

range	variable	before	correct
jsonb[]	row	row.status (composite access on a document)	row->>'status'
composite array	item	item->>'name' (extraction from a row)	item.name

It leaked outside comprehensions too — with a schema declaring name as text, item.name.size() rendered as LENGTH(item->>'name') purely because the variable was called item.

isNumericJSONField — field names

Nineteen field names (level, score, price, rating, megapixels, vram, helpful, …) decided whether an extracted JSON value got wrapped in ::numeric. visitCall already drives that from the compared type — which is exactly where v3.7.0 left it when it removed the matching heuristic from visitIdent. The list was redundant.

How

A comprehension variable is now bound together with whether its range yields JSON, decided by the element type: a jsonb[] column unnests to documents, an array of a composite type unnests to rows.

The key move is that such a variable is then treated exactly like one declared through WithJSONVariables, scoped to the comprehension body. That reuses the existing JSON path machinery instead of duplicating it — which nested access needs:

r.metadata.active  over a jsonb[]
  name-based:  r->>'metadata'.active    ← extracts to text, then dots into it
  now:         r->'metadata'->>'active'

The binding is scoped like iterVars, because comprehensions nest and an inner one may reuse a name the outer bound to a different kind of collection. There's a test for that.

With the object-access branch gone, visitSelect loses its three-way switch and becomes a straight "JSON path or column".

Two tests corrected

Both pinned the old behaviour:

test	was	now
filter with nested field access on JSON — range is jsonb[], so r is a document	r.metadata.active	r->'metadata'->>'active'
TestIssue85_SizeOutsideComprehension — name is a text column	LENGTH(item->>'name')	LENGTH(item.name)

The second's own comment ("item.name will be treated as a struct field, generating item->>'name' for JSON") described a text column, so it was already confused.

Notably (item->>'price')::numeric > 10 from docs/json-support.md is unchanged — it just gets there because items is declared jsonb and 10 is numeric, rather than because the variable is called item and the field is called price.

Tests

New comprehension_json_vars_test.go: a jsonb range with an unlisted variable name; a composite range with a formerly-listed name; a scalar array; the numeric cast without the name list; nested access; the documented jsonb array-value example; all six formerly-listed names outside a comprehension getting no special treatment; and nested comprehensions where the inner rebinds the outer's name to a different kind of range.

⚠️ Please rely on CI

Docker isn't available in my environment, so the 10 pg/ testcontainer tests fail locally — identically on main, so it's environmental. pg/provider_testcontainer_test.go holds exact-SQL assertions over real comprehension queries, so that job is the gate. Everything else is clean: go build, go vet, golangci-lint (0 issues), go test -short.

Breaking

Field access on a comprehension variable follows the schema: iterating a composite array yields column access, iterating a jsonb range yields extraction, whichever the variable is called. Callers who relied on a variable name to force JSON treatment should declare the range as JSON in WithSchemas.

Pre-existing, not touched

docs/json-support.md:145 documents jsonb_array_elements(order.items) for a jsonb array value, but the converter emits UNNEST — identically before and after this change. Separate issue.

🤖 Generated with Claude Code