fix(autocomplete): suggest clause keywords and correct columns after …

[thomaswasle]

closes #293.

Summary

• Keywords never suggested after FROM clause — The completion provider only
  offered keyword completions when no context columns were available. Removed the
  contextColumnSuggestions.length === 0 guard so clause keywords (WHERE, ORDER BY,
  GROUP BY, LIMIT, …) are always included alongside column and table suggestions.

• SQL keywords captured as table aliases — parseTablesFromQuery matched FROM users WHERE and registered WHERE as the alias, poisoning the alias map. Added a
  SQL_RESERVED set; any captured alias that is a reserved word is discarded and the
  table name is used as its own alias.

• Wrong columns in MySQL multiDb mode — When activeSchema is null (multiDb),
  getTableColumns was called without a schema, causing MySQL to fall back to
  information_schema and return system columns instead of the user's table columns.
  Fixed by adding an optional schema?: string field to TableInfo and populating it
  with the source database name when building effectiveTables in multiDb mode. Both
  the context-aware and dot-trigger paths now pass t.schema ?? schema.

• Column cache poisoning — The fallback that attempts column fetches before the
  tables list loads could receive an empty response (schema mismatch / connection not
  yet ready) and cache it, blocking all subsequent fetches for that table. Empty results
  are now never written to the cache.

Files changed

File	Change
src/utils/autocomplete.ts	Remove keyword gate; add schema-aware table lookup for dot-trigger; use t.schema in context-aware path; skip caching empty results
src/utils/sqlAnalysis.ts	Add SQL_RESERVED set; filter captured aliases against it
src/contexts/DatabaseContext.ts	Add optional schema?: string to TableInfo
src/pages/Editor.tsx	Annotate each table with its source database when building effectiveTables in multiDb mode

Test plan

• MySQL multiDb: type SELECT * FROM <table> → columns from the correct database
  appear
• MySQL multiDb: type SELECT * FROM <table> WHERE → clause keywords (AND, OR,
  …) and column names both appear
• Type SELECT * FROM <table> WHERE <partial> → matching column names filter
  correctly
• Dot-trigger table. → columns from the correct per-database table appear
• Single-database connections: keywords still appear; dot-trigger still works
• Non-MySQL drivers: no regression in keyword or column suggestions

[kilo-code-bot]

CRITICAL: Missing 'using' in SQL_RESERVED set

USING is a standard SQL keyword in JOIN ... USING(...) clauses. The fromPattern regex captures the word after a table name as a potential alias, so FROM a JOIN b USING(id) incorrectly registers using as the alias for b. This breaks dot-trigger autocomplete for that table.

Suggested change

	'asc', 'desc', 'null', 'with', 'exists', 'all', 'any',
	'asc', 'desc', 'null', 'with', 'exists', 'all', 'any', 'using',

[kilo-code-bot]

WARNING: Alias dot-trigger uses wrong schema lookup in multiDb mode

When typedName is an alias (e.g. u aliasing users), this looks up the table list by the alias instead of the resolved actualTableName. In multiDb mode foundTable will be undefined, so schema falls back to activeSchema (which is null), and MySQL receives no schema filter.

The context-aware path already looks up by actual table name — the dot-trigger path should do the same.

Suggested change

	const foundTable = tables.find(t => t.name.toLowerCase() === typedName);
	const foundTable = tables.find(t => t.name.toLowerCase() === actualTableName.toLowerCase());

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

The previous issues have been resolved in the latest commit.

Resolved Issues (2)

Severity	File	Line	Issue
CRITICAL	src/utils/sqlAnalysis.ts	10	Missing 'using' in SQL_RESERVED set
WARNING	src/utils/autocomplete.ts	157	Alias dot-trigger uses wrong schema lookup in multiDb mode

Files Reviewed (5 files)

• src/utils/autocomplete.ts — no issues
• src/utils/sqlAnalysis.ts — no issues
• src/contexts/DatabaseContext.ts — no issues
• src/pages/Editor.tsx — no issues
• src-tauri/Cargo.lock — generated file, skipped

---

_{Reviewed by kimi-k2.6-20260420 · 148,642 tokens}

[NewtTheWolf]

uhhh thx @thomaswasle i will take a look today! @debba u can assign it to me

[NewtTheWolf]

Tested this end-to-end on the demo stack and all four fixes work: in MySQL multiDb the columns now resolve to the real table instead of information_schema, clause keywords show up after FROM, WHERE is no longer captured as an alias, and partial-filtering + the dot-trigger both behave. No regression on Postgres. Nice fix 👍

One small thing I'd want completed before merge, plus a few non-blocking notes.

Requesting changes

• SQL_RESERVED is incomplete — it covers the common clause keywords but misses a few that can legally follow a table name, so they're still captured as aliases (the exact bug this set is meant to prevent): SELECT * FROM orders FOR UPDATE → for becomes an alias of orders; FROM t NATURAL JOIN u → natural. One-line addition — inline suggestion below.

Non-blocking (happy to spin any of these into separate issues instead of holding the PR):

• Denylist vs. parse depth — SQL_RESERVED patches a greedy regex that grabs the first word after the table as the alias. A negative-lookahead / clause-boundary parse would make the denylist unnecessary (no perpetual keyword maintenance). The completion above fixes the immediate case; this is the longer-term shape.
• multiDb same-name tables — tables.find(t => t.name === …) returns the first match, so if the same table name exists in two selected DBs the first DB's schema always wins, and db.table. qualifiers aren't parsed. Still strictly better than before (which returned no columns at all) — worth a follow-up for cross-DB disambiguation.
• Empty-result cache skip — deliberate per your comment (see inline); just one rare edge case to consider.
• Keyword clutter / duplicate labels — keywords now always render, so a column named like a keyword (count, name, value) shows twice (Field + Keyword). Relies entirely on sortText ordering. UX tuning.
• Three keyword lists — SQL_RESERVED overlaps SQL_KEYWORDS (autocomplete.ts) and the sets in sqlSplitter/classify.ts; a shared source would avoid drift.

Inline details below.

[NewtTheWolf]

Blocking (cheap): this set misses a few keywords that can legally follow a table name, so they're still captured as aliases — the exact bug it's meant to prevent:

• SELECT * FROM orders FOR UPDATE → for registered as alias of orders
• FROM t NATURAL JOIN u → natural as alias of t
• also FETCH (FETCH FIRST), WINDOW, LATERAL, STRAIGHT_JOIN (MySQL), TABLESAMPLE, QUALIFY

Adding them completes the fix:

Suggested change

	'asc', 'desc', 'null', 'with', 'exists', 'all', 'any', 'using',
	'asc', 'desc', 'null', 'with', 'exists', 'all', 'any', 'using',
	'for', 'fetch', 'natural', 'window', 'lateral', 'straight_join', 'tablesample', 'qualify',

(Longer term, a negative-lookahead in the alias capture would remove the need to maintain this list at all — but that's non-blocking.)

[thomaswasle]

@NewtTheWolf I decided to skip this and directly went for the long term solution.

[NewtTheWolf]

Non-blocking — the rationale in your comment is sound (empty ≈ transient/not-ready, retry is cheap) and the cache already has a TTL on success, so skipping empties is a reasonable trade-off.

One edge case to keep in mind: a genuinely empty relation (a 0-column view, or a table the backend can't introspect) is never cached, so it re-issues get_columns on every trigger that references it. Almost certainly fine given how rare that is — but if it ever shows up as IPC chatter, distinguishing "empty because not-ready" from "empty because actually-empty" (or a short negative-cache TTL) would bound it. Fine to leave as a follow-up issue.