[ 
https://issues.apache.org/jira/browse/CASSANDRA-7740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092741#comment-14092741
 ] 

Sylvain Lebresne commented on CASSANDRA-7740:
---------------------------------------------

Honestly, I'm not sure I understand your arguments. Since we want to accept 
"free-form" function body, we need to clearly delimit those body and whatever 
we use, we need clear escape rules. We already have such thing and that's 
called string constants. Why would we not reuse that? That's going to be *a 
lot* easier for all tools.

So let's first switch to having body as strings. Then, as as second step, we 
can add an alternative syntax for strings that do no require to escape single 
quotes. But there is no reason to limit that syntax to functions, it can just 
be an alternative string constant syntax. Like Postregsql does. And so this is 
a separate ticket.

bq.  we could also remove the K_END K_BODY completly and replace K_BODY with 
K_AS - have no preference for that

I do strongly prefer {{AS}}.

 

> Parsing of UDF body is broken
> -----------------------------
>
>                 Key: CASSANDRA-7740
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7740
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Sylvain Lebresne
>            Assignee: Robert Stupp
>
> The parsing of function body introduced by CASSANDRA-7395 is somewhat broken. 
> It blindly parse everything up to {{END_BODY}}, which as 2 problems:
> # it parse function body as if it was part of the CQL syntax, so anything 
> that don't happen to be a valid CQL token won't even parse.
> # something like
> {noformat}
> CREATE FUNCTION foo() RETURNS text LANGUAGE JAVA BODY return "END_BODY"; 
> END_BODY;
> {noformat}
> will not parse correctly.
> I don't think we can accept random syntax like that. A better solution (which 
> is the one Postgresql uses) is to pass the function body as a normal string. 
> And in fact I'd be in favor of reusing Postgresql syntax (because why not), 
> that is to have:
> {noformat}
> CREATE FUNCTION foo() RETURNS text LANGUAGE JAVA AS 'return "END_BODY"';
> {noformat}
> One minor annoyance might be, for certain languages, the necessity to double 
> every quote inside the string. But in a separate ticket we could introduce 
> Postregsql solution of adding an [alternate syntax for string 
> constants|http://www.postgresql.org/docs/9.1/static/sql-syntax-lexical.html#SQL-SYNTAX-DOLLAR-QUOTING].



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to