[
https://issues.apache.org/jira/browse/CASSANDRA-8374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14385503#comment-14385503
]
Robert Stupp commented on CASSANDRA-8374:
-----------------------------------------
Syntax for {{CREATE FUNCTION}} is now:
{code}
<create-function-stmt> ::= CREATE ( OR REPLACE )?
( ( NON )? DETERMINISTIC )?
FUNCTION ( IF NOT EXISTS )?
( ( <keyspace> '.' )? <function-name> )?
'(' <arg-name> <arg-type> ( ',' <arg-name>
<arg-type> )* ')'
( CALLED | RETURNS NULL ) ON NULL INPUT
RETURNS <type>
LANGUAGE <language>
AS <body>
{code}
{{CALLED ON NULL INPUT}} means that the function is always called.
{{RETURNS NULL ON NULL INPUT}} means that the function is not called if any of
the input parameters is {{null}}.
For user defined aggregates there are some special cases:
# A state function is not called, if the current state is {{null}} or any of
the aggregate argument values is {{null}}
# A final function is not called, if the state is {{null}} and the aggregate’s
return value will be {{null}} (we cannot just return the last state since
return and state types may be different).
I’m not fully sold on how it looks for {{RETURNS NULL ON NULL INPUT}} in CQL.
The snippet
{code}
CREATE FUNCTION ...
RETURNS NULL ON NULL INPUT
RETURNS text
...
{code}
looks a bit awkward to me due to the duplicated keyword {{RETURNS}}. I think we
should keep the {{RETURNS <type>}} as it is. But I’d like to propose the
following syntax change.
{code}
CREATE FUNCTION ...
( RETURNS <type> OR NULL ON NULL INPUT
| CALLED ON NULL INPUT RETURNS <type>
)
...
{code}
It’s syntactic sugar.
> 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
> Labels: client-impacting, cql3.3, docs-impacting, udf
> Fix For: 3.0
>
> Attachments: 8374-3.txt, 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)
