The only complication that I can imagine is with the NullPolicy, but I haven't tried to implement it myself.
This function may return NULL when neither of the operands is NULL. This is unusual for a function. Mihai ________________________________ From: Tanner Clary <tannercl...@google.com.INVALID> Sent: Thursday, February 22, 2024 4:45 PM To: dev@calcite.apache.org <dev@calcite.apache.org> Subject: Re: Some questions about calcite I feel like I'm missing something about this whole issue. We have implemented so many functions that there's probably an existing pattern for just about any issue with dialect parity we encounter. What's the core problem? What behavior is so difficult to emulate and why? Caican let me know if you want to pair I'm happy to manage the edge cases if you want. Tanner On Thu, Feb 22, 2024 at 4:34 PM Julian Hyde <jhyde.apa...@gmail.com> wrote: > I agree. https://issues.apache.org/jira/browse/CALCITE-6224 and its > accompanying PR muddies the waters because it also mentions Spark, Postgres > and “many databases”. The case should state that the function is consistent > with MySQL and returns NULL if the argument is non-positive. > > > On Feb 22, 2024, at 4:24 PM, Mihai Budiu <mbu...@gmail.com> wrote: > > > > In the case of log2 it's simple, because the documentation says that it > comes from the MySQL dialect. So there is a spec and a golden > implementation to compare against. > > > > I certainly won't object to implementing a separate log2 function that > is undefined for 0 and negative values (i.e., can return any value for such > arguments), let's just not pretend it's the MySQL function. > > > > Mihai > > ________________________________ > > From: Julian Hyde <jhyde.apa...@gmail.com> > > Sent: Thursday, February 22, 2024 4:05 PM > > To: dev@calcite.apache.org <dev@calcite.apache.org> > > Subject: Re: Some questions about calcite > > > > But what is the spec of the LOG2 function? It’s not in the SQL standard. > So, we need to write our own spec. We can say that LOG2(0) returns 42, if > we wish, and go implement our own spec. > > > > Yes, Calcite is a compiler, but it is also a standard library, and it is > also an extended library. LOG2 is in the latter category. If you, as a > vendor, don’t trust the implementation of LOG2 then you can exclude it from > your distribution. > > > > As an open source project we have to BOTH improve the quality of our > core and lower the barrier to contributions to the non-core code. We have > to recognize that not everything is the same standard. And I think vendors, > like your company, who want to deliver a high-quality experience should put > barriers around what features are trusted. > > > > Julian > > > >> On Feb 22, 2024, at 3:42 PM, Mihai Budiu <mbu...@gmail.com> wrote: > >> > >> 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. > >> > > > >
