m-novikov / tree-sitter-sql

SQL syntax highlighting for tree-sitter
MIT License
110 stars 32 forks source link

Some questions about roadmap and making contributions #19

Closed pplam closed 2 years ago

pplam commented 2 years ago

Hi @m-novikov , I recently had the need to parse SQL and finally found your project. It's an awesome project and is under active development. I would like to make some contribution to this project but I have a few questions for you

  1. Regarding the scope and extent of support for SQL syntax, do you have a roadmap or goal?
  2. Will you accept PRs contributed to this project?

Looking forward for your response, thank you!

m-novikov commented 2 years ago

Regarding roadmap I am focusing on PostgreSQL compatible syntax. Ideally first milestone would be full support of commonly encountered statements (SELECT, INSERT, UPDATE, DELETE) to allow embedding syntax highlighting to other languages. After this I want to take a closer look at supporting pl/sql and function definitions.

Note that tree-sitter mostly focuses on parsing for editors so there is less strictness in terms of correctness of parsing. Which means there maybe be constructions that will be parsed successfully that aren't necessarily correct syntax in terms of database.

Yes, I'll most definitely accept contributions. Feel free to submit PR or outline the idea so I can get better grasp on your use cases.

pplam commented 2 years ago

Understood that, actually I want a parser that can process PostgreSQL and MySQL (and ideally more dialects) compatible grammars. Consider that the PostgreSQL dialect is largely SQL standard compliant, if the basic syntax of PostgreSQL is supported, then most corresponding MySQL syntax is covered.

For MySQL specified features, is it possible if we add supporting for them? And in long term, do you have a plan to make the SQL parser more general to make it compliant with more dialect?

The next step, I think the supporting of PL/SQL and function definitions will be a great feature.

pplam commented 2 years ago

For the less strictness in correctness of parsing, it is ok for me. I want the maximum of successful parsing and the minimum of parse errors. And for me, the more SQL syntax covered by the grammar defined in grammar.js, the better.

pplam commented 2 years ago

@m-novikov I added some more supportings & made a few improvements, but I failed to push the changes to a new remote branch. Please grant the push permission to me. Thanks!

m-novikov commented 2 years ago

Appreciate it :) It's better to create fork and submit a PR, it's sadly not possible for me to monitor and grant access to this repo due to security concerns.

pplam commented 2 years ago

Got it! Thanks @m-novikov

I submitted a PR#22 which contains some new supportings & improvements.

Please take your time to help me review this PR, thanks!