Description

When a VALUES clause is used as a data source inside a subquery, operations applied in the outer SELECT of that subquery (arithmetic projections, LIMIT, ORDER BY) are silently ignored. The subquery behaves as if it were just SELECT * FROM (VALUES ...) v(n), discarding any transformations or constraints.

This affects three distinct operations:

1. Arithmetic projections on VALUES columns are not applied
2. LIMIT inside a subquery over VALUES is ignored (all rows returned)
3. ORDER BY inside a subquery over VALUES is ignored (insertion order preserved)

All three work correctly when applied directly to a VALUES clause (not wrapped in a subquery).

Skipped tests: https://github.com/dolthub/doltgresql/blob/main/testing/go/values_statement_test.go#L189-L224

Repro

1. Arithmetic in subquery over VALUES

-- Returns original values (1, 2.5, 3) instead of doubled values (2, 5.0, 6)
SELECT * FROM (SELECT n * 2 AS doubled FROM (VALUES(1),(2.5),(3)) v(n)) sub;

Expected:

Actual:

The n * 2 expression is completely ignored.

2. LIMIT inside subquery over VALUES

-- Returns all 4 rows instead of only 2
SELECT * FROM (SELECT * FROM (VALUES(1),(2.5),(3),(4.5)) v(n) LIMIT 2) sub;

Expected:

Actual:

The LIMIT 2 is ignored.

3. ORDER BY inside subquery over VALUES

-- Returns rows in insertion order (3, 1.5, 2) instead of sorted order (1.5, 2, 3)
SELECT * FROM (SELECT * FROM (VALUES(3),(1.5),(2)) v(n) ORDER BY n) sub;

Expected:

Actual:

The ORDER BY n is ignored.

Notes

• Operations applied directly to VALUES (not inside a subquery) work correctly. For example, SELECT * FROM (VALUES(1),(2.5),(3)) v(n) LIMIT 2; returns 2 rows as expected.
• The bug only manifests when VALUES is nested inside a subquery that applies additional operations.