[
https://issues.apache.org/jira/browse/CASSANDRA-8374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14243922#comment-14243922
]
Robert Stupp commented on CASSANDRA-8374:
-----------------------------------------
bq. how a default value will work in practice
By example: (argTwo is irrelevant for this)
argOne is null/empty, argThree is null/empty -> function not called
argOne is null/empty, argThree is 4 -> function called with argOne = 42 and
argThree = 4
argOne is 2, argThree is 4 -> function called with argOne = 2 and argThree = 4
bq. be careful to not feature creep UDF before we have even released the first
version
Good point. If no one else comes up with a different opinion, I'll remove the
{{DEFAULT}} option.
bq. Not a terribly strong preference however
I like the per-arg (and return type) {{ALLOW NULL}}.
> 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
>
>
> 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)
