[psteinroe]

Stacked on #887.

Two details of the expand * code action from the analysis of #887.

Needless quotes

create table größen (größe int, "Ölstand" int, "Café" int);
select * from größen;
-- before: "größe", "Ölstand", "Café"
-- after:  größe, Ölstand, "Café"

quote_identifier only treated ASCII as plain. Postgres' lexer accepts any byte ≥ 0x80 in unquoted identifiers (ident_start/ident_cont in scan.l) and only folds ASCII letters, so names whose only non-lower-case characters aren't ASCII read the same without quotes. Upper-case ASCII letters and keywords other than unreserved ones are still quoted.

When the file is resolved

Editors ask for code actions on every cursor move, and the action resolved the whole file whenever the cursor's line contained a *: /* comments */, count(*), a * b and '*' included. On long files that is a full walk per cursor move, on top of the lint code actions.

expand_star::is_at_star scans the cursor's line and only says yes when the cursor is on a * token, or its qualifier, that follows SELECT, ,, ., RETURNING, DISTINCT, ALL, a ) (DISTINCT ON (...)), or nothing on that line (a * on a line of its own). In a function body on the line (as '...' or as $f$...$f$) it looks at the body. If the line doesn't scan on its own, like a line inside a multi-line string, any * still counts, as before. The resolver still decides whether there's something to expand, so this only skips walks.

Tests

• Unit tests: quoting of non-ASCII names; is_at_star for *, t.*, schema.t.* with the cursor on the qualifier, RETURNING *, a * alone on a line, count(*), multiplication, comments, string literals, and one-line function bodies.
• Workspace: expanding * over a table with non-ASCII column names, and no action on count(*) or inside a comment.

Not covered

The walk itself isn't cached on this branch; the cached walk for hover, inlay hints and semantic tokens is in #930 (on top of #888), and the code action can use it once both are in.

[psteinroe]

Shouldn't this be in server/features/expand_star?