Don’t let the perfect be the enemy of the good. Or as they say in open source, “Release early and often”.
Just about everyone who wants a LOG2 function is intending to apply it to positive numbers. So they won’t notice, or care, that the function doesn’t do exactly what they expected when you apply it to zero. You should release a LOG2 function that does the right thing for the positive numbers, if it’s less effort than handling all non-negative numbers. Don’t listen too much to the QA folks. Their job is to find the corner cases. But they forget that the corner cases are usually not as important as the core cases. So, let the QA folks log bugs (or you can a log yourself, when you submit an imperfect implementation). Just release early and often. Also, note that the implementation of a function in Java, so that it can be executed by Calcite, does not have to be the *only* implementation. It is often better to have the JDBC adapter push the function down. That is exactly what Bertil is doing for geospatial functions in https://issues.apache.org/jira/browse/CALCITE-6239, and Tanner is looking at making a map so that we know which SQL dialects can implement which functions. Julian > On Feb 22, 2024, at 6:11 AM, Cancai Cai <can...@apache.org> wrote: > > When I was working CALCITE-6224 > <https://issues.apache.org/jira/browse/CALCITE-6224>, I encountered some > problems and I always had some doubts in my heart. > I thought about it for a long time, maybe I think I already understand the > doubts in my heart. > > As @mihaibudiu said, Java grammar has its own type rules, and SQL has its > own type rules. What calcite currently does is to use Java syntax to adapt > to the SQL rules of each database to complete execution optimization. In > some extreme scenarios, the SQL rules of various databases are > inconsistent. Calcite > needs to be sure to adapt to these extreme situations. But, I mean, if one > day, for example, mysql returns the result of log10(0) as an error instead > of null, then does calcite need to adapt to the new version of mysql? If it > adapts to the new version of mysql, does calcite still need to adapt to the > old version of mysql? It seems to me that this may be a paradox. Because in > my opinion, it is very difficult to 100% adapt to the SQL dialect of all > databases, because different dialects of each database need to be > considered, and there may even be differences between versions of different > versions of databases. > > Can anyone explain it to me? I would be very grateful.
