Our great sponsors
- Appwrite - The open-source backend cloud platform
- InfluxDB - Collect and Analyze Billions of Data Points in Real Time
- Onboard AI - Learn any GitHub repo in 59 seconds
-
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.
-
-
Appwrite
Appwrite - The open-source backend cloud platform. Add Auth, Databases, Functions, and Storage to your product and build any application at any scale while using your preferred coding languages and tools.
-
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 some 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 libg_query, and to psteinroe (https://github.com/psteinroe) who the creator and maintainer of the LSP.
[0] LSP: https://microsoft.github.io/language-server-protocol/
[1] pganalyze: https://pganalyze.com/
-
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 ?
-
vscode-postgres
PostgreSQL extension for vscode providing explorer, highlighting, diagnostics, and intellisense
The vscode-postgres extension is pretty good for crafting queries.
-
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
-
Can you try to get it added to Mason so people don't have to try and do a custom install?
-
InfluxDB
Collect and Analyze Billions of Data Points in Real Time. Manage all types of time series data in a single, purpose-built database. Run at any scale in any environment in the cloud, on-premises, or at the edge.
-
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/
-
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/
-
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.
-
pglast
PostgreSQL Languages AST and statements prettifier: master branch covers PG10, v2 branch covers PG12, v3 covers PG13, v4 covers PG14, v5 covers PG15
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 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
-
pspg
Unix pager (with very rich functionality) designed for work with tables. Designed for PostgreSQL, but MySQL is supported too. Works well with pgcli too. Can be used as CSV or TSV viewer too. It supports searching, selecting rows, columns, or block and export selected area to clipboard.
> 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).
-
PostgreSQL
Mirror of the official PostgreSQL GIT repository. Note that this is just a *mirror* - we don't work with pull requests on github. To contribute, please see https://wiki.postgresql.org/wiki/Submitting_a_Patch
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.
-
-
-
-
sqlfluff
A modular SQL linter and auto-formatter with support for multiple dialects and templated code.
It has tons of annoying quirks, but I couldn't imagine running a DBT project without it: https://github.com/sqlfluff/sqlfluff
-
Onboard AI
Learn any GitHub repo in 59 seconds. Onboard AI learns any GitHub repo in minutes and lets you chat with it to locate functionality, understand different parts, and generate new code. Use it for free at www.getonboard.dev.
