Postgres Language Server: Initial Release • Hacker News Board

Re: Postgres Language Server: Initial Release

#41

Post by norman784 » Sat, Mar 29, 2025, 7:12 PM UTC

steinroe wrote: post #26

edg5000 wrote: post #23

Assuming it works, this is a game changer. Currently I use DBeaver for SQL linting/autocomplete which is great. What about parsing Py/C++/Rs/Java for SQL statements in strings? Perhaps by using multiline strings, VS Code could use a different language server depending on wether the line is within an SQL multiline string? That would allow statically checking and autocompleting SQL statements within strings in code. Wh…

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 c…

Could this run as a Typescript Language Server plugin? AFAIK Svelte, Vue, etc does something similar to be able to use Typescript inside their own template files. It will be a game changer if you could use the Postgres Language Server inside your codebase.

Re: Postgres Language Server: Initial Release

#42

Post by t1mmen » Sat, Mar 29, 2025, 7:38 PM UTC

tmountain wrote: post #30

For anyone struggling to manage their PL/pgSQL codebase via migration files. This is a game changer. https://github.com/t1mmen/srtd

Oh, fun to see my project mentioned on HN! I’m glad to see it’s useful to others :)

Re: Postgres Language Server: Initial Release

#43

Post by t1mmen » Sat, Mar 29, 2025, 7:46 PM UTC

Really excited about trying this, great job so far!

I think formatting/prettier-type functionality was mentioned as a possibility of this project, is that still in the cards?

(I can’t seem to find a formatter that understands stored procedure; does it even exist?)

Re: Postgres Language Server: Initial Release

#44

Post by piokoch » Sat, Mar 29, 2025, 9:07 PM UTC

homebrewer wrote: post #16

steinroe wrote: post #2

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…

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

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

Re: Postgres Language Server: Initial Release

#45

Post by javajosh » Sat, Mar 29, 2025, 10:07 PM UTC

steinroe wrote: post #2

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…

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

Re: Postgres Language Server: Initial Release

#46

Post by thom » Sat, Mar 29, 2025, 10:09 PM UTC

d4rkp4ttern wrote: post #7

steinroe wrote: post #2

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…

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

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.

Re: Postgres Language Server: Initial Release

#47

Post by steinroe » Sat, Mar 29, 2025, 10:23 PM UTC

javajosh wrote: post #45

steinroe wrote: post #2

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…

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

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.

Re: Postgres Language Server: Initial Release

#48

Post by steinroe » Sat, Mar 29, 2025, 10:25 PM UTC

norman784 wrote: post #41

steinroe wrote: post #26

Earlier quoted context omitted.

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 c…

Could this run as a Typescript Language Server plugin? AFAIK Svelte, Vue, etc does something similar to be able to use Typescript inside their own template files. It will be a game changer if you could use the Postgres Language Server inside your codebase.

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

Re: Postgres Language Server: Initial Release

#49

Post by steinroe » Sat, Mar 29, 2025, 10:27 PM UTC

t1mmen wrote: post #43

Really excited about trying this, great job so far! I think formatting/prettier-type functionality was mentioned as a possibility of this project, is that still in the cards? (I can’t seem to find a formatter that understands stored procedure; does it even exist?)

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.

Re: Postgres Language Server: Initial Release

#50

Post by steinroe » Sat, Mar 29, 2025, 10:30 PM UTC

vendiddy wrote: post #37

I'm very happy that something like this exists! I'm wondering why have there have been no good IDE experiences so far for Postgres? Or put another way, what has been the most challenging part of building this? Nothing I have tried so far comes close to what I'm used to with statically typed languages. One would think something as strict as Postgres would have good autocomplete by now but I've yet to find something.

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.