[
https://issues.apache.org/jira/browse/DERBY-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488898
]
Andrew McIntyre commented on DERBY-1623:
----------------------------------------
Hi Manish,
You are of course correct, any expression that returns a character data type is
allowed. I just couldn't find it in the few minutes that I took last night to
look in the spec. Found it today, the relevant portion is:
<character value expression> ::=
<concatenation>
| <character factor>
<character factor> ::=
<character primary> [ <collate clause> ]
<character primary> ::=
<value expression primary>
| <string value function>
and valueExpressionPrimary() in the parser covers everything necessary here. I
expected to be able to replace characterValueExpression() with:
ValueNode
characterValueExpression() throws StandardException:
{
ValueNode expr;
}
{
LOOKAHEAD(2)
expr = valueExpressionPrimary(false)
{
return expr;
}
|
expr = characterValueFunction()
{
return expr;
}
}
JavaCC does not complain about this, but generates an invalid grammar: you get
a compile error because JavaCC split the parse tree for the subquery choice of
valueExpressionPrimary but failed to push the inSelectClause boolean that was a
part of the valueExpressionPrimary declaration into the new node. JavaCC bug?
Not sure, i'll investigate later.
> Add ANSI TRIM implementation
> ----------------------------
>
> Key: DERBY-1623
> URL: https://issues.apache.org/jira/browse/DERBY-1623
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Reporter: Emmanuel Bernard
> Assigned To: Manish Khettry
> Attachments: 1623-parser-guess.diff, AnsiTrimTest.java
>
>
> JPA is requiring databases to support this ANSI feature esp the ability to
> chose the trimmed character
> TRIM([ [ LEADING | TRAILING | BOTH ] [ chars ] FROM ] str)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
