LucidDB / luciddb

DEFUNCT: See README
https://github.com/LucidDB/luciddb
Apache License 2.0
53 stars 24 forks source link

[FRG-155] string literals spanning multiple lines no longer work in sqlline #717

Closed dynamobi-build closed 12 years ago

dynamobi-build commented 12 years ago

[reporter="jvs", created="Mon, 26 Jun 2006 18:44:08 -0500 (GMT-05:00)"] See luciddb/test/sql/udr/udf/contains_number.sql for an example.

This used to work, but was broken by eigenchange 7026. Note that you have to run it from stdin; it never worked via !run script.

I would say it's minor except that we don't really want to break a feature that was already working in sqlline.

I will temporarily disable the contains_number.sql test until this is fixed.

dynamobi-build commented 12 years ago

[author="angel", created="Tue, 27 Jun 2006 10:04:07 -0500 (GMT-05:00)"] This is because '\r' and '\n' was not allowed in the string literal by CommonParser.jj. Any reason for that? If not, I will change CommonParser.jj to allow the '\r' and '\n' in the string literal and that should fix the problem. Note that the !run script always treated multiline statements as having multiple lines and that's probably why it didn't work via the !run script.

dynamobi-build commented 12 years ago

[author="jvs", created="Tue, 27 Jun 2006 11:06:09 -0500 (GMT-05:00)"] No valid reason that I can see from section 5.3. I think long ago and far away in Saffronland, CommonParser.jj originated from from a grammar for the Java language, so that's probably why it excludes the EOL chars.

Something else I noticed while reading through 5.3 (syntax rule 4):

"4) In a , , , or
   , a shall contain a ."

We currently accept

'a very long broken-up ' 'literal string'

but this rule says that should be illegal, and we should instead required

'a very long broken-up '
'literal string'

(C++ string-pasting doesn't require a newline, but apparently SQL:2003 does.)

dynamobi-build commented 12 years ago

[author="angel", created="Tue, 27 Jun 2006 22:33:59 -0500 (GMT-05:00)"] Should be fixed by eigenchange 7062.

 And the validator enforces that

'a very long broken-up ' 'literal string'

is illegal (see SqlValidatorTest.testStringLiteralBroken)