[jira] [Updated] (CASSANDRA-7740) Parsing of UDF body is broken

2014-08-19 Thread Robert Stupp (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Stupp updated CASSANDRA-7740:


Attachment: 7740.txt

New patch with just the {{Cql.g}} and {{cql3handling.py}} changes.
No C* code changes necessary.

 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
 Fix For: 3.0

 Attachments: 7740.txt


 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)

[jira] [Updated] (CASSANDRA-7740) Parsing of UDF body is broken

2014-08-19 Thread Robert Stupp (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Stupp updated CASSANDRA-7740:


Attachment: (was: 7740.txt)

 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
 Fix For: 3.0

 Attachments: 7740.txt


 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)

[jira] [Updated] (CASSANDRA-7740) Parsing of UDF body is broken

2014-08-18 Thread Sylvain Lebresne (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sylvain Lebresne updated CASSANDRA-7740:


Reviewer: Sylvain Lebresne  (was: Tyler Hobbs)

 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
 Fix For: 3.0

 Attachments: 7740.txt


 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)

[jira] [Updated] (CASSANDRA-7740) Parsing of UDF body is broken

2014-08-16 Thread Robert Stupp (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Stupp updated CASSANDRA-7740:


Attachment: 7740.txt

Rebased against trunk

 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
 Fix For: 3.0

 Attachments: 7740.txt


 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)

[jira] [Updated] (CASSANDRA-7740) Parsing of UDF body is broken

2014-08-16 Thread Robert Stupp (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Stupp updated CASSANDRA-7740:


Attachment: (was: 7740.txt)

 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
 Fix For: 3.0

 Attachments: 7740.txt


 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)

[jira] [Updated] (CASSANDRA-7740) Parsing of UDF body is broken

2014-08-16 Thread Robert Stupp (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Stupp updated CASSANDRA-7740:


Attachment: (was: 7740.txt)

 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
 Fix For: 3.0

 Attachments: 7740.txt


 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)

[jira] [Updated] (CASSANDRA-7740) Parsing of UDF body is broken

2014-08-16 Thread Robert Stupp (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Stupp updated CASSANDRA-7740:


Attachment: 7740.txt

 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
 Fix For: 3.0

 Attachments: 7740.txt


 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)

[jira] [Updated] (CASSANDRA-7740) Parsing of UDF body is broken

2014-08-15 Thread Tyler Hobbs (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tyler Hobbs updated CASSANDRA-7740:
---

Reviewer: Tyler Hobbs

 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
 Fix For: 3.0

 Attachments: 7740.txt


 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)

[jira] [Updated] (CASSANDRA-7740) Parsing of UDF body is broken

2014-08-14 Thread Robert Stupp (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-7740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Stupp updated CASSANDRA-7740:


Attachment: 7740.txt

Patch for first string-style variant.
Will open a separate ticket for pg-style variant.

 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
 Fix For: 3.0

 Attachments: 7740.txt


 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)