[
https://issues.apache.org/jira/browse/CASSANDRA-8374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14263833#comment-14263833
]
Sylvain Lebresne commented on CASSANDRA-8374:
---------------------------------------------
bq. I think you may be overlooking the option of doing something other than
returning null or raising an error when a null argument is passed.
I don't think I do. I said earlier:
bq. the overwhelming majority of functions have only 2 reasonable ways to
handle null inputs: either throw, or return null. There is certainly functions
for which it makes sense to return a non-null value on null inputs, but it's
pretty rare.
to which you answered
bq. Agreed.
I'm not at all arguing that we shouldn't have the {{CALLED ON NULL INPUT}}
option, we absolutely should. I'm saying that functions that actually handle
null in a meaningful way are very rare (I would argue especially for database
functions that are mainly "pure" mathematical functions) and so they're not
meaningful to picking our default. Further, I'm saying that when we'll add an
extended standard library of out of the box functions (which we'll almost
surely do, with at least basic math, string manipulation and date related
functions), 99% percent of those functions will return null on null inputs
(because again, throwing instead means the function can't be use in select
clauses which is not an ok limitation), the 1% remaining being of those rare
functions that return some other value. If we disagree on that, then I'm
curious what your concrete plan for handling null in those functions would be,
but if we agree, then I think this is a pretty clear indication that this
should be the default for UDF.
bq. As a summary - am I right that we
We haven't totally agreed yet on the default part. But that's otherwise a good
summary of what I personally think we should do.
> 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, 8473-2.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)
