Contributing

[JohannesKnopp]

Hi, I've stumbled over this project as it was available as the postgres language server in neovim / Mason, and I've switched over from pgFormatter now in my project as well, as it worked really well for me so far and the DX is really good.

@psteinroe I really like what you've done so far, and would love to contribute if possible. How do you prefer contributions to be handled? Are there any issues you think would be suitable for a first contribution?

Thank you :)

[psteinroe]

hey @JohannesKnopp, thanks for the kind words!

the following items are open, ordered by complexity

• test the formatter on large sql bodies to find and fix small issues like format --write strips double quotes from quoted policy names #748
• find a solution for the limitation around comments in the formatter. the AST does not contain comment nodes and its an upstream limitation, and I would like to get around it by extracting the comments and moving them above the statement to not loose them.
• add more type-aware rules to our linter. most of the open issues are due to limitations of the simple EXPLAIN-based "type-checking". we want to replace it with more type-aware rules. this will require a few changes to the linting infrastructure, e.g. adding a table to the in-memory schema cache when we encounter a CREATE TABLE statement. Any statements that follow will then be evaluated as if that table exist in the database.

happy to support and provide more details! are you familiar with rust?

[JohannesKnopp]

Hey @psteinroe,

I'm familiar with Rust, and I think your first point is a good entry point for me, to also get to know the codebase a bit better. I was thinking about looking for big corpora of SQL files (e.g. public migration files of public postgres projects, https://github.com/supabase/postgres/tree/develop/migrations/db/migrations, https://github.com/discourse/discourse/blob/main/db/structure.sql, etc.) and look for AST differences between the original files and the post format --write files.

Funnily enough, I also came across your second point yesterday as well, as I had a comment in a stored procedure, which got removed. I ended up using COMMENT ON FUNCTION <fn> IS '...' instead.

[psteinroe]

Hey @JohannesKnopp,

sounds good, thanks for the support!

fyi: we do have a failsafe implemented that will fail the formatter and not write its output if the ast before and after do not match. No need to manually compare them. If the formatter succeeds you know they match. You can find it in the entrypoint of the pretty printer.