steinroe

5 ms·

1.
by steinroe 3mo ago
afaik, you should be able to use named session to achieve this: https://herdr.dev/docs/persistence-remote/
2.
by steinroe 3mo ago
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 retrie
3.
by steinroe 1y ago
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
4.
by steinroe 1y ago
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
5.
by steinroe 1y ago
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.
6.
by steinroe 1y ago
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
7.
by steinroe 1y ago
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
8.
by steinroe 1y ago
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.
9.
by steinroe 1y ago
thanks for the report! that was an oversight. pr with the fix is up.[0] [0] https://github.com/supabase-community/postgres-language-serv...
10.
by steinroe 1y ago
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 reque
11.
by steinroe 1y ago
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.
12.
by steinroe 1y ago
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 sid
13.
by steinroe 1y ago
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-ch
14.
by steinroe 1y ago
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.
15.
Postgres Language Server: Initial Release(github.com)
362 points by steinroe 1y ago|52 comments
16.
by steinroe 1y ago
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 an
17.
by steinroe 2y ago
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
18.
by steinroe 3y ago
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 re
19.
by steinroe 3y ago
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 p
20.
by steinroe 3y ago
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
21.
by steinroe 3y ago
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 ar
22.
by steinroe 3y ago
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 w
23.
by steinroe 3y ago
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 basica
24.
by steinroe 3y ago
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). W
25.
by steinroe 3y ago
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.
26.
by steinroe 3y ago
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.
27.
by steinroe 3y ago
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.
28.
by steinroe 3y ago
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.
29.
by steinroe 3y ago
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 acc
30.
by steinroe 3y ago
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,

More ›