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 >
