The SAFE_* functions do this. On Thu, Feb 22, 2024 at 4:58 PM Mihai Budiu <mbu...@gmail.com> wrote:
> 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. > > >> > > > > > > > >
