[steinroe]

Hey HN!

We have released the initial version of the Postgres Language Server we started working on almost two years ago[0]. You can try it out by downloading the binary from the repo[1]. It is also available on npm, as a vscode extension and via nvim-lspconfig and mason.[2]

We fell into plenty of rabbit holes along the way, but dug our way out of each. We're now using mostly pragmatic, almost naive solutions for our problems.

You can find more details in this blog post.[3]

Try it out and let us know what breaks. Bug reports, ideas, and contributions are all welcome-especially if you want to hack on some Rust.

Last, but not least, we want to give a shoutout to Biome[4]. We spent a lot of time studying their codebase and have been adopting many of their approaches. We wouldn't be here without their work.

[0] Announcement Show HN: https://news.ycombinator.com/item?id=37020610

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

[2] Installation Guides: https://pgtools.dev/#installation

[3] Blog Post: https://www.supabase.com/blog/postgres-language-server

[4] Biome: https://biomejs.dev

[mjw1007]

I suggest it would be helpful if the README's intro expanded a little more on the project's scope. "for postgres" is a bit vague, and "focusing on developer experience and reliable SQL tooling." doesn't tell me much about what it actually does.

If I was coming to this project for the first time I think the questions I'd immediately like the answers to are:

- What language is this language server for? Is it just for SQL proper, or for PL/pgSQL, or writing C extensions, or what?

- What makes it PostgreSQL-specific? Is it just that it follows PostgreSQL's dialect of SQL?

- Does it expect to be told about your database's schema? And if so, do you tell it by giving it a database connection, or letting it see files defining the schema, or what?

[juleswritescode]

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.

[jmholla]

> 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.

It'd be nice if users could manually obtain and provided that information.

[trillic]

I agree. But you can just point it to an empty db with your schema.

[kiwicopple]

For those who don’t read the blog post, I thought this was pretty cool:

> The idea to use tree-sitter in addition to libpg_query came from feedback[0] on our previous HN post, so thank you for that

https://news.ycombinator.com/item?id=38570680

[d4rkp4ttern]

What does a language server do? Asking for those who missed the memo.

[pdpi]

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.

[thom]

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.

[rad_gruchalski]

> 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

[steinroe]

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.

[ayhanfuat]

I am pretty excited about this. Thank you for all your effort.

My initial tests fails whenever there are CTEs. Are they not supported? I get

   processing panicked: cannot start statement within statement at Some(Token { kind: With, text: "with", span: 0..4, token_type: ReservedKeyword })

whenever I try a file containing a CTE (this one was a file with this query: `with test as (select 1 as id) select * from test;`).

[steinroe]

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

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

[juleswritescode]

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.

[juleswritescode]

steinroe is a very fast man: https://github.com/supabase-community/postgres-language-serv...

[ayhanfuat]

That's great, thank you both!

[homebrewer]

> we started working on almost two years ago

Jesus, this really puts it into perspective how much effort JetBrains have put into their IDEs, which have had superb support for all popular SQL dialects for as long as I can remember. Thank you for providing the community with a FOSS alternative, because IIRC there wasn't anything remotely comparable to JetBrains up until now.

[steinroe]

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.

[piokoch]

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).

[vaylian]

Language servers rule. Thanks for doing this!

[steinroe]

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.

[crooked-v]

Any chance this will include formatting in the future?

[juleswritescode]

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

[javajosh]

What are some of the most impactful/eye-opening lessons you learned from biome?

[steinroe]

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.