From my understanding, the way this check is used in this rule is to actually preclude the rule from being applied at all if certain conditions are not met.
If you have a query which is not transformed into a semantically equivalent query (i.e., it doesn't provide the same result for any possible input), then you have a certain bug. Maybe you can provide the example that you are worrying about to make the discussion concrete. Mihai ________________________________ From: Nick Riasanovsky <n...@bodo.ai> Sent: Friday, August 16, 2024 1:00 PM To: dev@calcite.apache.org <dev@calcite.apache.org> Subject: Re: Null Policy for Casting to a NOT NULL type Hi Mihai, I'm not actually referring to "which cast is taken" but instead other functionality that uses Strong and its interaction with cast. In particular, in JoinProjectTransposeRule there is a check to ensure that a function has the same result both before an after the join if its on the outer side of the join that requires `Strong.allStrong(leftProject.getProjects())`. The cast to a NOT NULL type passes this check per its policy, which is why I asked if this policy is correct. Sorry for any confusion and thank you for your help, Nick Riasanovksy On Fri, Aug 16, 2024 at 1:22 PM Mihai Budiu <mbu...@gmail.com> wrote: > First (I haven't checked), but is the behavior of casts governed by Strong? > > If you are attempting to cast a value that is null at runtime to a > non-null value the result should be a runtime exception. > SQL is full of runtime exceptions - any arithmetic that overflows will > produce a runtime exception. > It's true that this particular exception probably signals a bug in either > the type checker or the optimizer. > > Mihai > ________________________________ > From: Nick Riasanovsky <n...@bodo.ai> > Sent: Thursday, August 15, 2024 6:26 PM > To: dev@calcite.apache.org <dev@calcite.apache.org> > Subject: Null Policy for Casting to a NOT NULL type > > Hi everyone, > > I have a question about the logic in Strong.java. My understanding is that > this file and the corresponding policy dictates a function's relationship > to NULL, which can translate to optimization like removing an IS NOT NULL > call or enabling pulling a function above/below an outer join. My question > is about the policy assigned to CAST, which is assigned ANY. This seems > reasonable in most cases, but I'm wondering what the defined behavior > should be if the data is ever cast to a NON-NULL type. > > For context, I'm encountering an issue in my project that integrates > Calcite where a non-null cast is being pulled above an OUTER JOIN, which is > problematic because the data is still being cast to NON-NULL. This doesn't > seem correct/desirable, so I'm wondering if this could partially be due to > an issue with the CAST definition. I can work on producing a Calcite only > reproducer if that would be more helpful. > > Thanks, > Nick Riasanovsky >
