Do we expect to hint/complete table aliases? #31

New Issue

2026-06-12T14:08:36+01:00

oli commented

2026-06-12 14:08:36 +01:00

This query text:

select c.name as customer_name, o.id as order_id, o.date, sum(ol.count*p.price) as total from Orders o join OrderLines ol on o.id=ol.order_id join Products p on p.id=ol.product_id join Customers c on c.id=o.customer_id group by o

Hint panel says "no such column o on table Orders, OrderLines, Products, Customers" - not sure whether we expect to hint/complete the o alias here, but the hint message is misleading in any case.

This query text: ``` select c.name as customer_name, o.id as order_id, o.date, sum(ol.count*p.price) as total from Orders o join OrderLines ol on o.id=ol.order_id join Products p on p.id=ol.product_id join Customers c on c.id=o.customer_id group by o ``` Hint panel says "no such column `o` on table `Orders, OrderLines, Products, Customers`" - not sure whether we expect to hint/complete the `o` alias here, but the hint message is misleading in any case.

claude-clouddev1 commented

2026-06-12 15:02:25 +01:00

Fixed in 7e4bc12.

Both halves of the report addressed:

Misleading message — a bare in-scope table alias (o) used where a column is expected no longer reports no such column o on table Orders, .... It now emits a targeted hint: o` is a table alias — write `o.<column>` to reference one of its columns (and the table_used_as_column variant for an un-aliased table source). It's a drop-in replacement for unknown_column at the same span/Error severity, so the validity indicator, token overlay and hint panel behave exactly as before — only the wording changes.
Hint/complete the alias — yes, we now do. At a bare SQL-expression slot (projection / WHERE / GROUP BY / HAVING, not already past a qualifier.) completion offers each FROM source's qualifier (its alias if it has one, else the table name) as a Tab candidate, so o is discoverable on the way to o.<column>. On an exact-alias partial the alias source steps aside so the targeted hint surfaces instead of sibling-alias noise.

Two correctness guards (each with regression tests):

SQL only — the hint is gated to role == "sql_expr_ident". The simple-mode DSL Expr reaches the same code path but has no table.column syntax, so a DSL bare table-name ref keeps the generic unknown_column (advising the qualified form there would be wrong).
Effective-qualifier match — an aliased source must be referenced by its alias; FROM a x … GROUP BY a is invalid SQL, so the shadowed real name a falls through to unknown_column rather than being advised as a.<column>.

A genuine unknown column still reports no such column verbatim.

Decision recorded in ADR-0032 Amendment 3. +10 tests; full suite green (2417 pass, 1 ignored).

Fixed in `7e4bc12`. **Both halves of the report addressed:** 1. **Misleading message** — a bare in-scope table alias (`o`) used where a column is expected no longer reports `no such column o on table Orders, ...`. It now emits a targeted hint: **``o` is a table alias — write `o.<column>` to reference one of its columns``** (and the `table_used_as_column` variant for an un-aliased table source). It's a drop-in replacement for `unknown_column` at the same span/Error severity, so the validity indicator, token overlay and hint panel behave exactly as before — only the wording changes. 2. **Hint/complete the alias** — yes, we now do. At a bare SQL-expression slot (projection / `WHERE` / `GROUP BY` / `HAVING`, not already past a `qualifier.`) completion offers each FROM source's qualifier (its alias if it has one, else the table name) as a Tab candidate, so `o` is discoverable on the way to `o.<column>`. On an exact-alias partial the alias source steps aside so the targeted hint surfaces instead of sibling-alias noise. **Two correctness guards** (each with regression tests): - **SQL only** — the hint is gated to `role == "sql_expr_ident"`. The simple-mode DSL `Expr` reaches the same code path but has no `table.column` syntax, so a DSL bare table-name ref keeps the generic `unknown_column` (advising the qualified form there would be wrong). - **Effective-qualifier match** — an aliased source must be referenced by its alias; `FROM a x … GROUP BY a` is invalid SQL, so the shadowed real name `a` falls through to `unknown_column` rather than being advised as `a.<column>`. A genuine unknown column still reports `no such column` verbatim. Decision recorded in **ADR-0032 Amendment 3**. +10 tests; full suite green (2417 pass, 1 ignored).

claude-clouddev1 closed this issue

2026-06-12 15:02:35 +01:00

oli referenced this issue from a commit

2026-06-12 21:35:58 +01:00

fix(completion): treat a bare in-scope table alias as an alias, not an unknown column (#31)

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: oli/rdbms-playground#31