[Feature Request] PostgreSQL LSP integration & schema-aware SQL autocompletion

[arashm]

Summary

Add intelligent, schema-aware autocompletion to the SQL editor, ideally backed by a PostgreSQL language server (LSP). Today the editor offers syntax highlighting and line numbers via GtkSourceView, but no completion. For a database client, completion is one of the highest-leverage features — it's where most of the day-to-day typing happens.

Motivation

• Writing queries against an unfamiliar or large schema means constantly switching to the sidebar to look up exact table and column names. Inline completion removes that round-trip.
• codd already introspects the connected database (tables, views, columns, indexes, constraints, FKs) to power the browser, so much of the metadata needed for completion is already available in-process.
• This is a major differentiator versus a plain text editor and brings codd closer to feature parity with heavier Electron-based tools, while staying native.

Proposed solution

Two complementary layers, which could be delivered incrementally:

1. Schema-aware completion (no external dependency)

• Implement a GtkSource.CompletionProvider that feeds suggestions into the existing GtkSourceView editor.
• Source completions from the schema metadata codd already loads for the active connection:
  • Table / view / materialized-view names
  • Column names (ideally context-aware: prioritize columns of tables referenced in the current FROM/JOIN)
  • Schema names, functions, and common SQL keywords
• Trigger on . (qualified names like schema.table, table.column) and on demand

2. Full LSP integration (richer)

• Wire the editor to an external PostgreSQL language server to add hover docs, diagnostics, type-checking, signature help, and more robust context-aware completion.
• Candidate server: Postgres Language Server (supabase-community/postgres-language-server) by the Supabase community. It's written in Rust, built on Postgres' own parser (libpg_query) for full syntax compatibility, and builds an in-memory schema cache from a live DB connection to drive autocompletion and type-checking — a natural fit for codd's existing Rust/sqlx stack.
• Rust has mature LSP client building blocks (e.g. lsp-types, async-lsp/tower-lsp ecosystem) that fit the existing async stack.

[anil-e]

Hi @arashm,
thanks for the detailed proposal!

I agree that this would be a very useful feature, and I think it fits Codd really well. I am going to look into this as the next larger feature I work on.

My current plan is to start with an in-process completion provider using the schema information Codd already has, rather than starting with a full LSP integration right away. That should keep the first version simpler and easier to ship, while still covering the most common workflow.

The LSP route is definitely interesting, but I want to evaluate it separately once the native completion path is in place, because I think it has some packaging and lifecycle implications for a Flatpak app.