You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We can start return_type deprecation after this PR
I recommend we do not deprecate return_type - after this PR I think we have a nice API. Namely most simple uses can use return_type and ones that need more control (like returning nullability, or getting scalar args) can use return_type_from_args
Uh oh!
There was an error while loading. Please reload this page.
Having
return_type
does not really reflect the UDF actual nullability.the following problems exists when UDF wrongly report their nullability:
Disallow optimization based on the expressions nullability.
For example lets assume I have 2 columns:
col1
which is i64 without nullscol2
which is i64 with nullsand the expression
ceil
does not does not implementreturn_type_from_args
, so by default thenullability
istrue
can't optimize the following query and
this means that I can can't optimize this query
to be this:
because
ceil
says that the nullability is true even though the input expression is not nullablethe same can be for not able to remove the expression
array_remove_all(array, null)
if the array expression report that it is nullable while it is notWrong types
creating the wrong type:
should be nullable
false
but becausemake_array
implementreturn_type
it does not get that informationThe text was updated successfully, but these errors were encountered: