[psteinroe]

The column names we give unnamed select list entries (our port of Postgres' FigureColname) were wrong in three places, and both banDuplicateColumnAssignments (new in #885, recommended) and unknownColumn trust them:

• An unaliased scalar subquery was named ?column?. Postgres transforms the subquery first and takes the name of its column, so (select max(a) from t) is max.
• (t.c).arr[1] was named after c, because only the last indirection item was looked at. Postgres takes the last field name anywhere in the list: arr.
• Every CASE was named case. Postgres uses the name of the ELSE result if that is a good name, so case when ... then 1 else a end is a.

So valid migrations failed the linter:

create view max_and_min as select (select max(a) from t), (select min(a) from t);
-- before: × Column ?column? is specified more than once.
-- after:  nothing (Postgres names the columns max and min)

create view v as select (t.c).arr[1], c from t;
-- before: × Column c is specified more than once.

create view va as select (select max(a) from t);
select max from va;
-- before: × Column max does not exist.

The casts of subqueries follow from this: (select max(a) from t)::text keeps max, and (select 1)::text stays ?column? (the subquery's name is a strong name, so the cast doesn't replace it with text).

What changed

• EXPR_SUBLINK takes the name of the first column of the subquery: the alias of the first entry of its left-most select, otherwise the name figured for its value, column1 for VALUES, and unknown for a * (it expands to a column of the relation). The name is strong, as in Postgres.
• ColumnRef and A_Indirection take the last field name in the list, ignoring * and subscripts, and an indirection without one falls back to its argument.
• CASE ports the ELSE handling.
• MULTIEXPR_SUBLINK has no name, as in Postgres (it only appears in UPDATE ... SET (a, b) = (select ...)).
• figure_column_name returns None for a top-level *, instead of ?column? for */t.*. The resolver already expanded those itself; output_name (ORDER BY / GROUP BY references) no longer gets a bogus ?column? for them.

Every name was checked against Postgres 15 (create view + pg_attribute), and the three duplicates in the new spec are rejected by Postgres with 42701.

banDuplicateColumnAssignments now also runs in postgres_regress.rs, so any finding on a statement Postgres accepted fails CI on every version. The corpus is clean; its three findings are on rejected statements (update.sql 42601, create_table.sql and typed_table.sql 42701) and show up in the per-version snapshots.

The rule docs said insert into t (a, a) fails with 42601. Postgres raises 42701 duplicate_column (column "a" specified more than once); only duplicate SET assignments are 42601.

Tests

Spec files banDuplicateColumnAssignments/unnamed_columns.sql (accepted views, CREATE TABLE AS, SELECT INTO with subqueries, set operations, VALUES, casts, field subscripts, CASE), unnamed_duplicates.sql (the cases Postgres does reject), and unknownColumn/unnamed_view_columns.sql. Regress snapshots for 15–18 gain the three true positives.

Not covered

The subquery's first column is unknown if it is a * (we'd need the relation's first column), so that case reports nothing.