|
If you were logged in you would be able to see more operations.
|
|
|
Farrago
Created: 17/Mar/06 03:07 PM
Updated: 21/Jun/06 03:08 PM
|
|
| Component/s: |
SQL Parser
|
| Affects Version/s: |
None
|
| Fix Version/s: |
None
|
|
|
Currently, the parser binds a COLLATE clause to an identifier. But SQL2003
Part 2 Section 6.28 says it's applicable to an entire character string expression
(nothing special about identifiers). So, we need a new operator to represent
it, and class SqlIdentifier should not have a collation attribute.
------- Comment #1 From John Sichi 2005-02-01 19:57 [reply] -------
I am deleting the current incorrect parser definitions, because they're getting
in the way for UDT DDL.
------- Comment #2 From John Sichi 2005-02-02 01:33 [reply] -------
I am disabling SqlParserTest.testLiteralCollate; please re-enable it once
fixed.
------- Comment #3 From John Sichi 2005-02-02 01:43 [reply] -------
Note that everything I said about identifiers goes for literals as well (e.g.
SqlCharStringLiteral shouldn't have a collation attribute).
------- Comment #4 From John Sichi 2005-02-02 01:51 [reply] -------
Also disabling a bunch of tests in SqlValidatorTest.
------- Comment #5 From Wael Chatila 2005-02-02 21:25 [reply] -------
accept
------- Comment #6 From John Sichi 2005-02-03 02:55 [reply] -------
Also disabled some tests in Rex2CalcPlanTest. All disabled tests are marked
with comment referring to dtbug 280.
------- Comment #7 From Stephan Zuercher 2005-06-01 08:49 [reply] -------
Reassign from Wael to component owner.
------- Comment #8 From John Sichi 2005-06-08 14:56 [reply] -------
Reassigning to Julian for dispatch. This is the bug with the description of
the other mistakes Wael made with collation support.
|
|
Description
|
Currently, the parser binds a COLLATE clause to an identifier. But SQL2003
Part 2 Section 6.28 says it's applicable to an entire character string expression
(nothing special about identifiers). So, we need a new operator to represent
it, and class SqlIdentifier should not have a collation attribute.
------- Comment #1 From John Sichi 2005-02-01 19:57 [reply] -------
I am deleting the current incorrect parser definitions, because they're getting
in the way for UDT DDL.
------- Comment #2 From John Sichi 2005-02-02 01:33 [reply] -------
I am disabling SqlParserTest.testLiteralCollate; please re-enable it once
fixed.
------- Comment #3 From John Sichi 2005-02-02 01:43 [reply] -------
Note that everything I said about identifiers goes for literals as well (e.g.
SqlCharStringLiteral shouldn't have a collation attribute).
------- Comment #4 From John Sichi 2005-02-02 01:51 [reply] -------
Also disabling a bunch of tests in SqlValidatorTest.
------- Comment #5 From Wael Chatila 2005-02-02 21:25 [reply] -------
accept
------- Comment #6 From John Sichi 2005-02-03 02:55 [reply] -------
Also disabled some tests in Rex2CalcPlanTest. All disabled tests are marked
with comment referring to dtbug 280.
------- Comment #7 From Stephan Zuercher 2005-06-01 08:49 [reply] -------
Reassign from Wael to component owner.
------- Comment #8 From John Sichi 2005-06-08 14:56 [reply] -------
Reassigning to Julian for dispatch. This is the bug with the description of
the other mistakes Wael made with collation support. |
Show » |
|
Bug
Open
Trivial
Collation Clause Should be on Expression Instead of Identifier
select 'a' collate x from t
gives a parse error 'Expecting <COLLATION_NAME>'. The end-user cannot be
expected to know that collation names are of the form xxx$yy[$zz]. The error
should be from the validator, not the parser, and should say 'Unknown
collation 'x''.
Another query:
select 'a' collate x$y from t
gives java.nio.charset.UnsupportedCharsetException. Again, this should be a
validation error not a parse error, something like 'Unknown charset 'y''.