I agree that this is a problem. Assuming that a database dialect improves over time, if someone is connecting to version 5 of a database, they would like Calcite to generate the best SQL for version 5, but not use features that were added in version 6 or later. To minimize the amount of code, we would probably like a single adapter for all versions of that database, possibly even sharing code with other databases that have similar dialects.
The solution starts with the test suite. If someone wants the adapter to generate different SQL for versions 4, 5, and 6, then they should write tests to ensure that. To make those tests pass, they will need to change the dialect implementation so that it runs in different modes for different versions. I don’t think we need a high-level policy for how modes, or versions, are represented in various dialects. If the maintainers follow the tenets of agile (write tests, refactor to improve reuse and reduce tech debt) then we will have an acceptable solution. Following those tenets will sometimes cause people to merge dialects of similar databases (e.g. MySQL and MariaDB). Julian > On Mar 17, 2025, at 7:52 AM, Cancai Cai <can...@apache.org> wrote: > > Hello, everyone in the Calcite community. > > Calcite currently does not emphasize the version or even the adapter > adaptation for the adaptation of various database dialects, but as more and > more dialects are adapted, this may become a hidden danger. For example, a > database modifies a certain syntax in a certain version, but Calcite has > already adapted the previous syntax, then do we still need to be compatible > with the modified syntax? There are many similar examples, such as adaptation > functions, etc. > > I think we can find a way to determine a standard, describe it in the > document and tell users, such as determining it according to the latest > version, or do you have better suggestions? > > Best wishes, > Cancai Cai
