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
