You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
a project of the company I am working for, requires a high performance SQL parser such as this one. However, we would mainly require the Exasol syntax (which is a lot like Oracle syntax) and we may also need DB2 (z/OS and LUW) syntax.
We are considering and willing to implement the needed syntax and would love to officially contribute that syntax here and share it with the community. But before we start working on it, we have to check our internal policies, whether we are allowed to do so or not. Furthermore, we would like to ask you as well for your opinion on this, since Exasol is not a very popular or widespread RDBMS and the readme specifically states the following:
The most commonly accepted PRs add support for ... a popular RDBMS ... will likely be accepted after a brief review.
We want to make sure, that our contribution would be be accepted and supported (being reviewed) by the responsible contributors of this project (of course only if it meets all the standards and contribution guidelines).
I am looking forward to a hopefully positive reply!
I checked the syntax of the supported Oracle dialect against the Exasol SQL reference. On a first glance, mainly stuff like the IMPORT keyword and things like CREATE SCRIPT [...] and EXECUTE SCRIPT [...] are not part of the Oracle dialect.
Which issues did you face when parsing Exasol SQL's with this software?
If you want to contribute the dialect, open a PR. You can take a look at PRs that have added a dialect, e.g. this one #2380 which is still open for review for the Doris dialect.
Also, even if your PR does not end up getting merged, you can always use your own fork and apply patches on top of it for your own use case. Since you are stating that you need this feature for the company you are working for, it should not be a problem to support your own contributions on your own fork.
I would start by testing your SQL's using the Oracle dialect and once you have figured out which specific Exasol only features you are missing, you can start drafting your PR.
Activity
ssteinhauser commentedon Dec 1, 2025
Hello, are there any thoughts or any opinion on this?
tempusari commentedon Aug 25, 2026
Hi @ssteinhauser ,
I checked the syntax of the supported Oracle dialect against the Exasol SQL reference. On a first glance, mainly stuff like the
IMPORTkeyword and things likeCREATE SCRIPT [...]andEXECUTE SCRIPT [...]are not part of the Oracle dialect.Which issues did you face when parsing Exasol SQL's with this software?
If you want to contribute the dialect, open a PR. You can take a look at PRs that have added a dialect, e.g. this one #2380 which is still open for review for the Doris dialect.
Also, even if your PR does not end up getting merged, you can always use your own fork and apply patches on top of it for your own use case. Since you are stating that you need this feature for the company you are working for, it should not be a problem to support your own contributions on your own fork.
I would start by testing your SQL's using the Oracle dialect and once you have figured out which specific Exasol only features you are missing, you can start drafting your PR.
I think this issue can be closed.
Best regards
LucaCappelletti94 commentedon Sep 28, 2026
Closing as answered.