[
https://issues.apache.org/jira/browse/CASSANDRA-8374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14246553#comment-14246553
]
Sylvain Lebresne commented on CASSANDRA-8374:
---------------------------------------------
The thing is, if you have a simple function like
{noformat}
CREATE FUNCTION incr(x int) RETURNS int LANGUAGE JAVA AS 'return x + 1';
{noformat}
then I'm not sure it's very friendly for
{noformat}
SELECT a, b, incr(c) FROM foo;
{noformat}
to crash when it encounter a row with no value for {{c}}. Especially since that
would be throw in the middle of the execution and we don't even have a good
exception to return for that. Besides, since a {{null}} means "there is no
value", it makes a lot of sense to me that the function is simply not applied
and "there is no value" is returned. In fact, I'm kind of -1 for throwing an
exception in that particular case, because imho that would make UDT without
{{ALLOW NULLS}} largely unusable in practice.
Of course, when you have
{noformat}
SELECT * FROM foo WHERE v = incr(null);
{noformat}
then I can agree that that throwing an IRE is an option. But I wonder if
handling {{null}} differently in those two cases won't confuse people more than
if we have a single rule that is applied everywhere. Typically in something
like:
{noformat}
SELECT x, add(a, ?) FROM foo;
{noformat}
it feels more consistent to have the same behavior whether {{a}} or the bind
marker is {{null}}.
bq. handling the combination of UDA + non-ALLOW NULLS state function (thinking
about what happens when a ALLOW NULLS UDF is replaced by a non-ALLOW NULLS
variant)
I don't think we should allow such replacement. We should allow to replace a
function only if it has the exact same signature *and* the same handling of
nulls or it's going to be messy.
> Better support of null for UDF
> ------------------------------
>
> Key: CASSANDRA-8374
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8374
> Project: Cassandra
> Issue Type: Bug
> Reporter: Sylvain Lebresne
> Assignee: Robert Stupp
> Fix For: 3.0
>
> Attachments: 8473-1.txt
>
>
> Currently, every function needs to deal with it's argument potentially being
> {{null}}. There is very many case where that's just annoying, users should be
> able to define a function like:
> {noformat}
> CREATE FUNCTION addTwo(val int) RETURNS int LANGUAGE JAVA AS 'return val + 2;'
> {noformat}
> without having this crashing as soon as a column it's applied to doesn't a
> value for some rows (I'll note that this definition apparently cannot be
> compiled currently, which should be looked into).
> In fact, I think that by default methods shouldn't have to care about
> {{null}} values: if the value is {{null}}, we should not call the method at
> all and return {{null}}. There is still methods that may explicitely want to
> handle {{null}} (to return a default value for instance), so maybe we can add
> an {{ALLOW NULLS}} to the creation syntax.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
