If we can't even implement correctly the log2 function according to its spec, there is no hope that we will implement anything correctly.
I am not a QA person, but I am spending more than 50% of my time diagnosing and fixing bugs in Calcite. It's not fun. I would rather implement interesting new functionality. But I cannot tell a user of our tools "I have no idea whether the results you get using this tool will be correct. If you are lucky, they will be, don't worry about corner cases." Our goal is to use Calcite in a production environment. If Calcite is designed to be just a research tool, maybe we should make that clear. There are fundamental bugs in Calcite which have been there for a decade. Even basic things like arithmetic casts are still incorrect. Which is proof that once a bug is in, people are not incentivized to fix them. We should not let bugs in deliberately. They may essentially never get fixed. I don't think a compiler can cut any corners. The compiler is the foundation of an entire software ecosystem. If the foundation is broken, everything crumbles. Mihai ________________________________ From: Julian Hyde <jhyde.apa...@gmail.com> Sent: Thursday, February 22, 2024 3:28 PM To: dev@calcite.apache.org <dev@calcite.apache.org> Subject: Re: Some questions about calcite 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.
