steinroe

afaik, you should be able to use named session to achieve this: https://herdr.dev/docs/persistence-remote/

i wanted to build a formatter for my postgres language server but always knew i would never have the time for it. when claude code first came out, i gave it a shot, but it was too inconsistent and still needed too much handholding. i retried it again at the beginning of this year. like before, i set up the harness to run overnight, expecting to throw it away the next morning. but nope, it deliberately worked through all the syntax nodes and followed patterns closely enough so that a few hours of my work could make it ready for the pr.

I do not have experience with monaco, but you should be able to run the language server remotely and connect to it from the editor via the usual language server protocol.

we currently do not provide a wasm build which would enable us to run the server within the browser too, although that's something I am actively poking around with.

we write about this in the blog post, but the tldr is that the Postgres syntax is ever-evolving and very verbose. its almost impossible to properly parse Postgres code in a sustainable way. all these tools usually try to do exactly that and eventually give up. we are building upon libpg_query instead, which is the actual Postgres server code extracted into a C library. that parser is built to parse executable SQL though, so we had to find a few workarounds to make it work.

its still in the cards! it will be more like a pretty printer instead of a formatter though. Meaning we will prettify valid code only. but its a bigger effort, and we want to focus on a stable basis first.

I did some research on it and afaik, all these tools run their language services as typescript plugins within the tsserver itself. this means they do not communicate to their own language server running next to it. right now, I am thinking to a. make a wasm build work and then try my luck with the tsserver plugin and b. enable embedded sql support for typescript in the CLI at least by parsing the code with oxc

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.

that is really awesome! declarative schema management is also high on my bucket list, and might even become part of this project. thanks for sharing, will check it out.

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

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

its still a bit rough around the edges, but we hope to kaizen our way through based on the bug reports from the community!

about embedded sql: you are right, this must be solved on the editor side. in vscode, it should be possible via request forwarding [0]. for neovim there are plugins like otter.nvim [1].

and at least for js, we are planning to add direct support for it in our workspace api so that `postgrestools check file.ts` will emit diagnostics for embedded sql. this is only feasible because we can easily parse js/ts code in rust via oxc[2] though. are you aware of similar tools in other languages?

[0] https://code.visualstudio.com/api/language-extensions/embedd... [1] https://github.com/jmbuhr/otter.nvim [2] https://oxc.rs

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 something we are currently looking into for typescript. at first, I thought a tsserver plugin will do. but a bit of research suggested that such a plugin can not call other language servers. this must be solved on the editor side instead. in vscode, it should be possible via request forwarding [0]. for neovim there are plugins like otter.nvim [1].

and at least for js, we are planning to add direct support for it in our workspace api so that e.g. `postgrestools check file.ts` will emit diagnostics for embedded sql.

[0] https://code.visualstudio.com/api/language-extensions/embedd... [1] https://github.com/jmbuhr/otter.nvim

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.

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.

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

This is great! We've been using PostgREST along with a PostgreSQL-based queue to handle side-effects like sending webhooks after database operations (inserts/updates/deletes). The queue feeds into a node server that processes these tasks. However, this setup is becoming a performance bottleneck as we scale.

I'm exploring an alternative way to run logic asynchronously after db operations without the overhead, and I think using cdc to export jobs into an external queue is the way to go here. Essentially a lightweight alternative to Debezium with a better developer experience that is easier to manage. This crate could serve as the core of such a service.

sorry, I think I misunderstood your question!

after all, we did not implement a "real" parser. we just use libpg_query, the actual Postgres parser, and work around its limitations as good as possible. The implementation thereby required maximum flexibility. we never define any grammar other than "a select statement starts with a SELECT keyword".

that's a very interesting idea!

for now, our goal is to take the "easy" route with libpg_query and build a language server that provides basic lsp features for invalid sql, and advanced lsp features for valid sql as fast as possible. we then want to go back to the parser and replace the libpg_query-based approach with a more resilient alternative. as of now, the plan is to implement a handwritten recursive-descent statement by statement. will definitely do research to what extend we could leverage gram.y there, especially to potentially fast-track it.

thanks for the link, very interesting read! and you are right, libpg_query has its limitations.

the idea is to first implement the parser with libpg_query and work around its limitations as good as possible. Since the scan api also returns all tokens for invalid sql, the language server will then have basic features and syntax error diagnostics for invalid statements, and advanced features for valid ones. once the server itself is done, we want to go back to the parser and replace the libpg_query-based parser with a more resilient alternative statement by statement. ultimately, the libpg_query-based parser should just be the fallback.

that being said, very excited that there is so much development in postgres dx.

that's a huge task to take upon, looking forward to go through it! compared to you, we have gone the "easy" way and use the actual parser from the Postgres server. so no grammar definition and the like. our work was mainly around adapting libpg_query (which is build to parse executable SQL) for our use case.

in our specific case, we needed something handwritten for the statement-level parser anyways. And the requirements for the LL parser are very simple: extract individual sql statements from a source input. we just compare the next n tokens with a list of tokens from which any statement starts, which is straightforward to implement with a handwritten LL parser.

so after all, I would say its a decision based on the special requirements we have working around the limitation of libpg_query. I think its also the fastest one, but this was not the main reason.

that is definitely the goal, both a formatter and a linter. we want to add something like squawk and plpgsql_check directly to the language server, so you get eslint-like dx. with both the ast and the database schema at hand, you can basically add any rule you like.

and this is far out, but eventually we are maybe even able to combine the language server with declarative schema management and have go-to-definition etc working.

[0] https://github.com/sbdchd/squawk/tree/master [1] https://github.com/okbob/plpgsql_check

hey, author here. Thanks for posting it!

A bit of background: a few months ago we announced a Postgres language server[0]. A language server adds features like syntax error diagnostic and autocomplete to your editor (vscode, neovim, etc). We have iterated a lot on the parser over the past few months and want to share an update today.

the parser is a core piece of any language server that constructs syntax trees from the raw input string. Usually first an untyped concrete syntax tree (cst) that represents the syntactic structure of the input, and subsequently a typed abstract syntax tree (ast) containing the meaning of the source.

In our implementation, we leverage the actual Postgres parser to-do the heavy lifting. However, the parser is designed to parse executable SQL — not to provide language intelligence. For example, it does not handle incomplete inputs, and outputs just the ast, not the cst. To use it for a language server we had to work around these limitations as good as possible.

While we leverage procedural macros in rust to generate a lot of the repetitive parser code, there remains a portion that requires a bit of manual work. But the groundwork is completed, and we can finally start working on the data model and the actual server next. Our aim is to bring this to a usable state as swiftly as possible.

Huge shout-out to pg_analyze for creating and maintaining libpg_query[1], without which this project would not be possible!

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

[1] https://github.com/pganalyze/libpg_query

the language server protocol supports range operations, although I don’t know how many editors enable it. plus it’s arguably harder to implement. I will add benchmarks once the server is ready, and we can see how far we can get from there. thanks for the feedback!

it’s on the roadmap! once the parser is stable and an advanced and scalable data model is implemented, features like this will hopefully be quite straightforward to implement.

not yet, but we will add this. As of now, the project is just a poc to show that the approach of using libg_query to parse the source works. Most of the work is still ahead.

I will add it to mason once it’s in an usable state. Feel free to open a discussion or issue to keep track of the lsp registries.

this is exactly the reason why I started this project. every singe line of code is business logic if you write parts of your backend directly within the database. plus zero latency and no extra servers. I want to make this approach more accessible with this project.

we are using the actual Postgres server source to parse the sql file(s) into both an abstract- and a concrete syntax tree. Its bundled with the language server and therefore works standalone. We will add the option to connect to a database, but only to enable features such as autocompletion and code actions a la „Execute the statement under the cursor“.

agreed! especially for smaller teams and startups it can make a lot of sense to push more logic in the database, and I hope to make this a bit more approachable with this project.