Hacker News new | past | comments | ask | show | jobs | submit login
Postgres Language Server (github.com/supabase)
963 points by kiwicopple on Aug 6, 2023 | hide | past | favorite | 119 comments
hey HN. this is a Language Server[0] designed specifically for Postgres. A language server adds features to IDEs (VSCode, NeoVim, etc) - features like auto-complete, go-to-definition, or documentation on hover, etc.

there have been previous attempts at adding Postgres support to code editors. usually these attempts implement a generic SQL parser and then offer various "flavours" of SQL.

This attempt is different because it uses the actual Postgres parser to do the heavy-lifting. This is done via libg_query, an excellent C library for accessing the PostgreSQL parser outside of the server. We feel this is a better approach because it gives developers 100% confidence in the parser, and it allows us to keep up with the rapid development of Postgres.

this is still in early development, and mostly useful for testers/collaborators. the majority of work is still ahead, but we've verified that the approach works. we're making it public now so that we can develop it in the open with input from the community.

a lot of the credit belongs to pganalyze[1] for their work on libpg_query, and to psteinroe (https://github.com/psteinroe) who the creator and maintainer.

[0] LSP: https://microsoft.github.io/language-server-protocol/

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




Letss gooo!! Supabase keeps on delivering things that I need.

I am regularly surprised how bad the tooling is for SQL/databases. Especially that there is no decent formatter that supports plpgsql, and doesn't absolutely mangle your queries (sometimes actually breaking your queries..).

Best options atm are imo TablePlus and DataGrip, I have tried a bunch of options in vscode and although there are useful tools, it's all not really there.

(Also excited to see what else they will release this launch week!)


> I am regularly surprised how bad the tooling is for SQL/databases

Agreed. Even when using something open like SQLite, you will find a lot of difficulty in answering simple (to me) questions like "how do I parse this command text into an AST".


Agree, would love to see this built into TablePlus.

What I really want is a state-based way to define my database. EdgeDB & Prism have made some progress here but they really only handle table changes. Really wish this were built into Postgres somehow (or any solid migration story).

I want to be able to define my tables, views, functions and everything and the engine behind it automatically figures out all the necessary changes. For example, change a table (add a column or something) and it is smart enough to update any dependent views and functions. Including handling of data migrations.


fwiw, I personally am interested in this approach too[0]. I keep running into roadblocks around the ordering of events and some of the hairy issues around "destructive" actions (eg: renaming columns). i think we can get there, especially once we make progress with this LSP.

There are other notable mentions in this space:

Reshape: https://fabianlindfors.se/blog/schema-migrations-in-postgres...

Atlas: https://atlasgo.io/

A "custom" example on GitLab: https://gitlab.com/delibrium/delibrium-postgrest/-/tree/mast...

[0] https://github.com/kiwicopple/declarative-schemas


Glad to hear that! We’re using Hasura (started before Supabase was a thing, otherwise we’d be using Supabase) and their Rails inspired migration is quite good. However, we’ve run into the problem of modifying functions and views that are dependent on other things (often views and custom functions). It’s a real bear to make changes - it involves dropping multiple views/functions (in the correct order) before applying the new migration - and then carefully adding it all back and hoping nothing breaks.

I don’t like the solution of “stop using views and functions” as I prefer to use use the full power of Postgres (everything close to the data, less application level logic, great plugins). Not sure what approach should be taken to creat a state based migration solution, but it feels like the tech around Postgres, language servers, MML, etc has matured enough to solve the issue in an automated way.


On that topic, I’d love to see database logic presented in a folder like structure in the way that we’re used to with code (instead of just hidden in migration files. Maybe language server can help with that.


Thanks for the mention of Atlas <3


Supabase cli has a decent diffing option to generate migrations (not sure what they use, but it’s open source), it works quite decent for schema changes.

Not as advanced as you describe though, it won’t handle your data migrations.


> I am regularly surprised how bad the tooling is for SQL/databases.

This. I'd really like to have a working SQL pretty printer/formatter. Psql is great, but lacks autocompletion in several places.

That said, a big shoutout to pspg (https://github.com/okbob/pspg) - an excellent pager for psql (also for general csvs).


SQL pretty printers have probably the widest variety of possible "pretty" options to support. I've seen so many disagreements over the years on how the right way to print SQL is. For instance, I've gotten huge fights by saying that I prefer "Sentence case" (example: `Select * from someTable where someId in (select otherId from otherTable)`; only "top-level" introductory keywords get a single capital letter to make them easier to scan for like you are reading prose, kind of, and no semicolons unless entirely required such as the termination of a Merge statement) versus how many people still seem to be telnetting their SQL in 2023 from terminals or punch cards that mandate shouting SQL keywords in all caps everywhere.

(ETA: Being a big fan of Merge statements for a bunch of ETL trivia is partly how I got to "Sentence case". Merge statements are tough to read at the best of times and eliminating extraneous casing changes as noise by using more lower-case than not was a very useful thing to me. I don't need to highlight keywords versus everything else in a modern syntax highlighting bath, so casing becomes useful for way finding. A lower-case "select" is in the middle of something else.)


With A formatter in place, I'm generally much happier, even if I don't always agree with the structure.


Check out Beekeeper Studio


Will try!

It looks quite similar to table plus, any killer features I’m overlooking?


Love Beekeeper Studio!


A monthly fee? No thanks.


Sheesh. It's open source, has a free version, and then a premium version so the bootstrapped, not-VC backed, creators avoid starving themselves and their families while working on the tool...


The pricing looks like SaaS only. I'm happy to pay a one-time fee for software (even when it doesn't include future versions), but not a subscription, unless of course there is a common sense benefit to a subscription (like paying for additional support on top of the fixed price).

Anyways, once taking the time to re-read the pricing screen subtleties it is sort of a one-time fee (billed as one year of subscription to gain indefinite use), so kudos to the developer, but I have to say it's really non-obvious to me at least.

Also the availability of a community edition is great, but again non-obvious.


That's good feedback for the developer for sure.


Hi! I'm the bootstrapped, non VC backed creator of Beekeeper Studio. My open source version is good, probably too good, lol.

Thanks for the mention!


> probably too good, lol

Lol, this is too true. I use Beekeeper Studio every day. Every once in a while I think to myself, "I should see if the full version is worth paying for yet". Then I check out the features and, while they look great, the free version has absolutely everything I need.

Thanks for such a great product. I'll stop freeloading eventually!


Please make your screenshot carousel stop automatically rotating after it is interacted with; it's really hard to take in the details of the screenshots.


Good idea, I'll do that, thanks!


Sadly, this is why this space has laggard for so long. Devs don’t want to pay for tooling but expect others to pay for their product.


There is an important differentiator, though. I'm happy to pay _once_ for tooling as a product, and potentially for subsequent major versions. I am not, however, willing to be a source of MRR.


I generally agree with this. There’s only one or two tools I’ll begrudgingly subscribe to with this model. I would be way more inclined to use the tools if it were a single purchase and I’ll upgrade when I feel like it. I’m looking at you JetBrains and Adobe…


JetBrains offer perpetual fallback licenses together with their yearly subscriptions: https://sales.jetbrains.com/hc/en-gb/articles/207240845-What...


Then nag you and auto update you to the latest version without a perpetual license.


The stereotype of software devs being the absolute cheapest bastards, despite being well paid, lives on. These people put time and effort into building a thing, and giving them money for it is reprehensible?


I’m not the people you are responding to, but I’ll share my take as a dev who buys some tools and turns my nose at the others.

The difference is - whether it’s a purchase or a subscription.

I’ll happily buy a tool, and happily will buy upgrades every so often.

I will absolutely resist paying for subscriptions unless you are delivering some sort of continuous service and I won’t be fooled by gimmicky cloud integrations just to make that claim.


Same for me, I avoid subscriptions as much as possible.

I’m ok with the model of TablePlus however: pay for a license, it’s valid for a year, and at the end of the year you keep the current version available forever but no more updates. And you get a discount if you decide to renew your license


Agreed, a subscription model where you end up “owning” a particular version after reaching some milestone is ok with me. Sort of like a payment plan.

I’ve been a happy subscriber to Jetbrains Toolbox that has a similar model for many years now, and have interrupted and later resumed my subscription while being able to use the software in between.

100% against a subscription where you no longer able to use the software the moment you cancel your subscription after paying for years. Looking at you Adobe.


Tooling is quite good on comercial space, now on free beer side, it is another matter.


It has tons of annoying quirks, but I couldn't imagine running a DBT project without it: https://github.com/sqlfluff/sqlfluff


FWIW, the MS SQL tooling is decent... Hopefully this goes as far to understand the db/schema/table structure of a connected database.


SequelPro is quite decent for MySql.

Tooling for Postgres seems to be more for the technical who prefer command line than not.


Sequel Ace is the forked and actively developed version of Sequel Pro. I don't think the owners of Sequel Pro ever announced it was abandoned, but the GitHub repo's lack of what appears to be any real development activity certainly suggests it is.


That's great to know, thanks, I'll try it out.

At this point my muscle memory is on the Sequel Pro shortcut keys, except I'm finding myself around Postgres more and more.


Excited to see this - and excellent use case for libpg_query (I'm the original author and still help maintain it together with the rest of the team) and appreciate the shout out to pganalyze!

If anyone else has a use case for using the Postgres parser outside the server, we have a healthy ecosystem of libraries that build on the core C library (we maintain bindings for Ruby, Go and Rust ourselves), as well as various projects using it (e.g. sqlc uses it for a type-safe way for using hand-written SQL in Go): https://github.com/pganalyze/libpg_query#resources


With all the various systems making use of Postgres's parser, is there a reason that the Postgres team haven't "seen the writing on the wall" about the demand for their parser, and so extracted their parser into a standalone library?

I imagine that Postgres itself would then consume the parser library as a — possibly regularly-snapshot-vendored — static library dependency; while other applications and wrapper libraries would be free to consume it as a dynamic shared library; and it could be freely independently distro-packaged; and so forth. In other words, it would become a de-facto "libxml for SQL" — the kind of venerable C lib that you expect everything else to just be a wrapper around.

Is it just that doing this would involve making functions with internal linkage into functions with external linkage, and thereby preventing some WPO opportunities when compiling Postgres itself?


Generally I agree that this would be great to have, and Postgres does have a set of libraries it already maintains as part of the main source tree (i.e. libpq, etc), and there is a shared set of code between the backend and the "frontend" (https://github.com/postgres/postgres/tree/master/src/common). So theoretically you could imagine the parser moving into that shared code portion, sharing code but not necessarily requiring linking to a library from the backend.

However, the challenge from what I've understood from past conversations with some folks working on Postgres core is that the parser is currently heavily tied into the backend - note the parser isn't just the scan.l/gram.y file, but also the raw parse node structs that it outputs. You can see how many files we pull in from the main tree that are prefixed with "src_backend": https://github.com/pganalyze/libpg_query/tree/15-latest/src/...

Further, there isn't a canonical way to output node trees into a text format today in core, besides the rather hard to work with output of debug_print_parse - there have been discussions on -hackers to potentially utilize JSON here, which may make this a bit easier. Note that in libpg_query we currently use Protobuf (but used to use JSON), which does have the benefit of getting auto-generated structs in the language bindings - but Protobuf is not used in core Postgres at all today.

All in all, I think there is some upstream interest, but its not clear that this is a good idea from a maintainability perspective.


What kind of support do we have editor-side for swapping between "LSP contexts" automatically? If I'm editing a .cs file and my editor is using the C# LSP, then start something that a plugin <somehow> recognizes as entering into an SQL mode as I type `foo("SELECT ..` can that somehow trigger the pgsql LSP too?

(I'm a vim user but I'll accept a VS Code answer since that's basically "state of the art" when it comes to LSP and where most others get their inspiration from.)


To add to the correct IntelliJ answer: VSCode, on the other hand, does not allow for multiple language services or servers to handle the same file at the same time. Instead, any language support (always by means of extension, either built-in or external) has to individually add support for embedded languages, either using language services or request forwarding [1]. For example, the built-in HTML plugin includes JS support inside <script/> tags by simply spinning up its own tsserver [2].

This seems to have been a design decision from the very start, but I have a hard time understanding why. It seems like a conceptual mistake to me. It also eats up system resources like crazy, but that's a lost cause anyway. Instead of harnessing the capabilities of existing implementations, every "wrapper" kind of language needs to build its own solution, which leads to these solutions often not being great. For example, said HTML/JS solution has issues with external dependencies [3]. Or, I've been trying to enable support for CoffeeScript or Elm inside Vue Single File Component files, but I couldn't so far, even though I'm the author of the CoffeeScript extension. [4][5]

Any source file always has exactly one language type assigned to it (possibly auto-detected), so no, dynamically "switching" is not possible without manually changing it for the entire file. For things like SQL inside PHP, Jetbrains products really are superior.

[1] https://code.visualstudio.com/api/language-extensions/embedd... [2] https://github.com/microsoft/vscode/blob/7fd6f1b1d46bd2223a9... [3] https://github.com/microsoft/vscode/issues/26338 [4] https://github.com/vuejs/language-tools/issues/3200 [5] https://github.com/vuejs/vetur/issues/1184


I just want to say thanks for taking the time out to answer with technical attention and thoroughness!


I don't know if this exists but it could be done using Treesitter. This is already done for syntax highlighting, nvim could check the syntax from a string after a specific pattern, like gql`` in Typescript.

This should be configured by the user, idk if a default implementation could work correctly in all cases.


Neovim does this. For example, if you have two lsp configured in nvm-lspconfig.lua as follows, it will use a specific lsp tailored to either SQL or ruby:

-- Initialization of Neovim's LSP client local nvim_lsp = require('lspconfig')

-- Setup for the Ruby LSP nvim_lsp.solargraph.setup {}

-- Setup for an SQL LSP (assuming one exists with the name 'sql_lsp' in this example) nvim_lsp.sql_lsp.setup {}


I think what parent comment is asking for is the ability switch between languages withing a single file. I don't think this will work with the setup you described.


No, it would not.


JetBrains's IntelliJ and friends do that with language plugins. They detect the language according to keywords and patterns and are able to do highlighting and intellisense for multiple languages in a single file. I have not tried this with LSP though, because LSP support landed just in the last version.


Yeah, (neo)vim can do that for non-lsp with a filetype like html.css or similar whichbloads both syntax rules possibly with customizations to determine when it switches into which of the two modes. But again, I don’t know how that works with lsp.


In Intellij you can connect to the DB and get autocomplete in SQL strings.


I'm using Helix these days, but I seem to recall neovim handling markdown with code blocks fine.

Less sure about "minor" dsl-like support, like online css/html/js in php etc? (Or SQL strings in c# etc).


This is very cool! Does it also support extensions? For example, would it be aware of additional functions and handling of geometries if PostGIS is installed?


that's theoretically possible, but beyond the scope of the work we have planned in the near feature.

it's a great idea though - I will add it to the "Discussions" to track for the future. I can personally see the benefit of PostGIS support


Are you looking for contributions? Can I join the party?


yes, we'd love more contributors


I also wanted to ask about extensions. How does it work internally? Does it ask the database for parsing or does it have its own syntax analyzer?


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


Does it connect to your actual database as well to get the list of tables, columns, etc? Or just leverage the same code base to be able to parse the raw text without any data dictionary information into a parse tree?


it leverages your code-base, rather than connecting to your database. it uses to libpg_query (https://github.com/pganalyze/libpg_query) to construct the syntax tree which can then be used to for the LSP features


Ah, does that mean autocompletion for fields is off the table?


It will definitely be supported at some point. We will have some features that require a db connection, eg autocompletion or code actions such as „Execute the current statement“. But always as an opt in.


Great project that helps creating better DX for Postgres!

At Omnigres [1] we also use libpg_query for programmatic query manipulations as libpg_query has a deparser and that allows one to manipulate AST and output the text representation back.

I'm trying to find time to contribute Postgres 16 support to it!

[1] Omnigres: https://github.com/omnigres/omnigres


Thanks Yuri - and appreciate your contributions to libpg_query!

We at pganalyze have plans to add Postgres 16 support to libpg_query sometime between the RC1 and the final release - mostly to watch out for the rare case where a feature gets reverted during the beta releases.

If you'd like to have a go at it before then definitely welcome (here is some context on the extraction process using libclang: https://pganalyze.com/blog/pg-query-2-0-postgres-query-parse...), and we'll also need people to test the PR once available.


Thanks, looks very interesting.

I have a couple of questions:

1. Will I be able to use this in my IDE (say JetBrains or VSCode) alongside the programming language’s LSP? So that this project would only be in effect for the Pg SQL bits?

2. I am a Rust newbie but I’m an experienced developer. Is there any room for someone like me to contribute to the project?


I think paid jetbrains IDEs already do this on their own, as they embed datagrip, no?

It checks the syntax, gives you autocomplete based on the databases you are connected to, it even supports string language injection, so you'll get SQL autocomplete and checking for strings containing SQL in your code.

I'd love to understand what the advantages here are, other than the obvious one of being available for many editors as a language server.


I'm not sure I'm a power user enough to notice a difference but I've had tremendous luck with jetbrains datagrip (standalone and embedded) when dealing with PG syntax. The highlight and formatting work a treat.


Yes, the jetbrains already have all these features and more (such as reflecting pg functions, tables, columns, schemas, etc).

You wouldn't really notice a difference using this, except your general autocompletes would get worse, and very complex sql might get more correct (I break datagrip's parser occasionally)


1. yes this is possible, although it depends on your IDE. Here is a relevant discussion for eclipse (which also links to the VSCode implementation): https://github.com/eclipse/che/issues/4609. Note: i also didn't know how this worked, so I learned something today too.

2. Yes, absolutely. Feel free to reach out to me directly, or just start contributing directly if you want


1) looks like intelliJ paid versions support (or will support) LSPs soon. https://blog.jetbrains.com/platform/2023/07/lsp-for-plugin-d...

> Starting with the 2023.2 release cycle, the LSP API is publicly available as part of the IntelliJ Platform in the following IDEs: IntelliJ IDEA Ultimate, WebStorm, PhpStorm, PyCharm Professional, DataSpell, RubyMine, CLion, Aqua, DataGrip, GoLand, Rider


> 1. Will I be able to use this in my IDE (say JetBrains or VSCode) alongside the programming language’s LSP? So that this project would only be in effect for the Pg SQL bits?

I think that would depend on IDE support. For example, JetBrains IDEs have a feature for this.


> Not SQL with flavors, just Postgres.

I like the focus on this.


Can you try to get it added to Mason so people don't have to try and do a custom install?

https://github.com/mason-org/mason-registry/


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.


I am very curious to see how it develops. I'm currently working on multiple SQLPage [1] websites, and getting a better IDE experience would be awesome. Writing only SQL is refreshing compared to all the boilerplate required in traditional web dev, but the developer experience is not yet as polished as in, let's say, typescript.

[1] https://sql.ophir.dev


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.


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

I feel that this approach, while unfashionable, is actually pretty excellent most of the time.


This is amazing. I've been using DataGrip for working with Postgres in the past year and a half but I would much instead use VSCode for complex queries. I love how DB languages become more and more first-class citizens in the editor and LSP worlds instead of a special type of language with specialised tooling.


The vscode-postgres extension is pretty good for crafting queries.

https://github.com/Borvik/vscode-postgres


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.


Out of curiosity, how has it been working with the pganalyze team? It seems like Supabase has been able to collaborate really effectively with other teams in the Postgres space (including pgAdmin and pgmigra, for the `diff` migrations tooling), and it's wonderful to see!


> It seems like Supabase has been able to collaborate really effectively with other teams in the Postgres space (including pgAdmin and pgmigra, for the `diff` migrations tooling)

I'm thankful to Supabase for their efforts, but I'm not sure I'd pick pgAdmin and migra as examples of "really effective" collaboration with other teams: as far as I know, pgAdmin's CLI feature wasn't merged upstream and sits in an outdated Supabase fork of pgAdmin which doesn't fully support Postgres 15, and migra (which has been abandoned for a while) was just used as-is.


fwiw, pgadmin was not for a lack of trying: https://redmine.postgresql.org/issues/6304. I won't have many details about migra form the CLI team until they come online, but no doubt we'll pick up the migra support if it has been abandoned.

(but I agree with the sentiment: we can always find ways to be more collaborative)


Thank you for sharing that! It's unfortunate that the pgAdmin devs weren't interested, although I understand them wanting to keep it focused on being a GUI.


I agree. We've been on the other side of pull requests like this and I know how hard it can be to say "no, we need to stay focused". I appreciate their clear comms


actually I forgot to mention this one to Lukas in all the chaos leading up to our Launch Week. I will do it now

we talked in the past about using their library to extend some of Dan Lynch's work (https://github.com/pyramation/postgres-ast-deparser) to create a sort of "postgres package registry" with dynamic DDL introspection. No progress on that one yet, but I'm hopeful that we'll find the bandwidth for it one day.


This looks nice!

As someone interested in developing a client for it, I'm interested in couple of things: what are the features supported by it currently, the tweak-able configuration that can be passed to it and the various code action available. I like the way nil language server has documented it (https://github.com/oxalica/nil/tree/main/docs). Is there something equivalent available for this ?


it's very much still a "POC" to verify that the libpg_query approach works - perhaps I should have made that more clear from the description. We have a PR open which adds source code generation to the Rust crate which is close to merging.

your comment is useful and why we submitted this to ShowHN - it's easier to get these sort of early feature requests than in 3 months once we've implemented more functionality. I'll drop a note in GitHub Discussions to investigate the Nil approach.


Always wondered why something like this wasn't made earlier. Either way I'm happy that it's being made now, writing SQL in an IDE like this should be easier


IMHO having an SQL language server they does only parsing, ie. validates only syntax, is a bit like a Java language server that does parsing only — ie. does not check whether e.g. a given variable/method actually exists or whether types match.

The schema is so integral to SQL — since it defines precisely the valid names and types — that a language server that isn't aware of this is of limited use in practice.


Man I was just looking for this forever, you rock.


Very nice. Hope to see something along the lines of Prettier for SQL, one day. That's sorely needed.


I've been looking for something like this recently, and there are actually quite a few options. Unfortunately, they can only handle files up to a particular size. My use case is to pretty up a huge SQL dump so that I can grab it. Every existing tool tries to read the entire thing into memory, and ends up crashing.


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.


> A Language Server for Postgres. Not SQL with flavors, just Postgres.

My heroes, thank you for working on this.


This should work fine with vim-dadbod and vim-dadbod-ui... Right?


Nice. I've been thinking about writing a more "general" sql lsp using rust so I might have a read of how they're doing this.


It looks very barebones at the moment. Looks like they've just pulled down a tower-lsp boilerplate, the parser crate has a little bit more in it.


I am confused what this does.

Is it that I type in my IDE "SEL" and is suggests "SELECT"?

In which situation would this be useful?


it would also be able to suggest columns/fields from your database, as well as picking up errors. for example, given this table:

    create table profiles (
      id serial primary key,
      first_name text,
      last_name text
    );
and this query:

    select id, firstname from profiles;
it would then help to detect if you had an error in your select query (in this case, "firstname" should be "first_name"), and your code editor would show a warning, even before you try to run the code inside your database


I don't think it connects to a database, so it cannot suggest field names yet. Correct me if I'm wrong.


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.


Essentially, LSPs are generic implementations of features like autocomplete, expand selection, refactor, etc., with a standardized API.

Different editors and IDEs can use the same LSP, without the need to reinvent/reimplement the wheel.


It’s surprising how powerful Postgres is and seeing tools to make it easier seems extremely nice!


would love to take this for a spin in Emacs. I always lsp support for sql was lacking.


> Optionated Code Formatting

"Optionated"? Opinionated or optional? Or both?


sorry, I believe Philipp meant that you can "configure it" - similar to Prettier: https://prettier.io/docs/en/configuration.html

I've updated the Readme


I liked “optionated” it’s like opinionated but with BYO opinions


Looks great. Has anyone tried an integration with Emacs?


I would love to see Dbeaver integrate this!


I will have to test this.


[deleted]


The libpg query library has a very important problem: It does not work on windows https://github.com/pganalyze/libpg_query/issues/44

I'd recommend starting with fixing that instead. It would be much more helpful for the community.


Sounds like they’d love your contribution. I hate when people prescribe tasks to others like this.


yes, we (and I assume the pganalyze team) would always appreciate contributions

fwiw, we know of this limitation and decided the acceptable workaround for Windows devs is simply to host the language server and they can connect to it via TCP.


Can't you just give some love to the issue https://github.com/pganalyze/libpg_query/issues/44 instead ? As I said before this would be very helpful for the community because there are a lot of libraries that use libpg_query and cannot be used on windows (f.e see https://github.com/lelit/pglast/issues/7).

It seems that the only problem for fixing the problem is:

> Thanks for the offer, but the problem is our team being time limited / having an engineer with a Windows machine ready to take this on, not that we wouldn't want to pay someone to work on it :)

(https://github.com/pganalyze/libpg_query/issues/44#issuecomm...)

Hosting the LSP elsewhere is not really needed since if people wanted to go that way they could use Remote ssh (https://code.visualstudio.com/docs/remote/ssh) to host the whole dev environment on linux and connect to it.

Thank you


We at pganalyze would definitely welcome help here - and if anyone would like to give this a try - feel free to email me, happy to talk this through, email is in my profile.

Postgres itself supports Windows, the main challenge is identifying the relevant files to pull in (since we use a subset of the full source code), and testing the changes. It should be fairly quick for someone who has C development experience on Windows, with a working development environment.


cool, we’ll look into helping at an appropriate time. Since we are still developing the LSP, this issue isn’t affecting anyone

> the only problem for fixing the problem is

Hopefully it’s as easy as you make it sound!


After 5 years of spinning wheels, maybe it’s time to accept that Windows is a second-class citizen. That’s why WSL exists, after all.

(Speaking as someone who dreaded the “inevitable” victory of Windows on the desktop in the 90s I might be a little biased/overjoyed.)


Just use a serious development OS instead

;)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: