Thanks for the feedback. Good points, we'll improve the README.

Regarding your questions:

1. It's currently only for SQL statements, but we'll work on function bodies and PL/pgSQL soon. 2. Exactly, we follow the the PostgreSQL dialect (we use Postgres's parser) 3. You can give it a database connection and it will query some pg_catalog tables. If you don't provide connection details, we'll bypass features requiring that.

The Language Server Protocol is essentially a standard for editors to talk to language tooling. All the usual refactor/go-to-definition/auto-complete functionality you expect from a modern IDE is implemented in a language-agnostic way in the editor in terms of calls to the language server, and language servers then provide the actual concrete implementations of that functionality.

IIRC Microsoft defined the spec in the context of creating VS Code, but these days every editor and their uncle supports it (from Vim and Emacs to Sublime Text and even IntelliJ). You can get a solid IDE-like experience for most mainstream-ish languages, and on most editors, through LSP.

Basically every editor decided it would be cool to be as slow as Emacs (said with love, as an Emacs user), and so now all the clever stuff is done in potentially several out of proc web servers, each of which uses gigabytes of RAM.

> The Language Server Protocol (LSP) is an open, JSON-RPC-based protocol for use between source code editors or integrated development environments (IDEs) and servers that provide "language intelligence tools":[1] programming language-specific features like code completion, syntax highlighting and marking of warnings and errors, as well as refactoring routines. The goal of the protocol is to allow programming language support to be implemented and distributed independently of any given editor or IDE.[2] In the early 2020s, LSP quickly became a "norm" for language intelligence tools providers.[1]

https://en.m.wikipedia.org/wiki/Language_Server_Protocol

thanks for asking! its what provides all language intelligence features in your IDE. so autocompletion, diagnostics, syntax highlighting etc. the postgres language server currently supports autocompletion, syntax error highlighting, type-checking and linting.

thanks for the report! that was an oversight. pr with the fix is up.[0]

[0] https://github.com/supabase-community/postgres-language-serv...

Thanks for the report. Hmm, we have some tests for CTEs, so at least we tried to support them.

I'll file an issue with your exact query.

to put things into perspective: even though it took a lot of effort, it's just a side project by two people who used it to learn rust along the way. A full-time team would have finished much faster.

That's a bit of exaggeration, IntelliJ DB tool is okeish, but there is nothing special about it. Even rather dated SQL Squirell is equally good, or even better in some places (like keeping run sqls history, better configurability of unusual parameters of some more exotic databases, like, say, DB2).

my pleasure! I had my ide point to the debug build locally for over a year now, and it has been very rewarding to slowly see it mature (as in crash less) during my day job over time.

Definitely. Of course, I can't promise that we can make it work properly, but it's high on our todo list.

I learned rust by doing this project. didn't have much prior systems programming experience too. usually, I learn best by just trying things until they work, but building a language server is pretty complex. after reading through a lot of similar projects, biome was the easiest to reason about. and it has exactly the architecture I had in mind: a generic workspace api where the language server is just one of many entry points.