Data Model / "Great Tooling"

[benjamin-kirkbride]

I would like to discuss the Data Model.

Firstly, I completely agree with the rationale that a robust Data Model will make or break this initiative.

Can we get some clarity on what is meant by this section?

My interpretation (that I desperately hope is true) is that this is saying that this project is intended to become a platform/library to provide a standard interface to build Postgres Tooling on top of.

Assuming the above is the case, I have some thoughts.

If you have not yet read my thoughts on supporting extensions, please do so now as that is highly relevant to this.

Things I would like to see:

• A way to serialize and deserialize the datamodel, such that it can be used as an alternative to tools like migra or pyrseas.
• Python bindings (I can possibly help with this)

[psteinroe]

hey @benjamin-kirkbride,

thanks for the discussions and the very valuable feedback!

When I wrote the mentioned section about the data model, I was referring to an in memory database that incrementally computes the data that we need to fulfil the needs of a language server. for example, given the abstract syntax tree, compute the location of all function definitions to support "jump to definition". rust-analyser uses the salsa crate for the same. it will most likely be implemented in a similar manner.

The main goal of this project is the language server itself. The platform aspect I mentioned was rather about building tooling on top of the syntax tree exposed by the parser crate, and integrate existing tooling, such as the squawk linter, to improve their accessibility. in some sense, the language server would be the "ui" for these tools. users would not need to run it as an external cli tool, but have the lint error displayed as diagnostics right within their code. another example is a formatter: popular examples (e.g. pgFormatter) parse the source with a custom parser, which often does not work. since the language server includes a very robust parser based on libg_query, we will build our own opinionated formatter into the server, and make it accessible as a language server feature.

In summary, the goal of this project is a server that people can 1) build tooling into on top of the robust postgresql parser, and 2) make the tooling easily accessible to developers via the language server protocol.

I know this is very disappointing given your request. I will try to structure the codebase in a way that enable the use of only the parser or the data model (including serialisation), and I am happy to explore possibilities from that. But the scope of the project is quite significant already, and the prime focus will be the language server, and not a library.