[
https://issues.apache.org/jira/browse/DERBY-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490686
]
Andrew McIntyre commented on DERBY-1623:
----------------------------------------
Hi Manish,
Sorry I didn't have time to come back to this sooner. Your new grammar looks
great. It avoids the multiple levels of lookahead into valueExpressionPrimary
that led to the compile error that I was seeing, and I tried throwing numerous
malformed and properly formed trim statements at it and everything worked
pretty much as expected, including statements with dynamic parameters and
subqueries. I didn't come close to trying out all the possible paths through
valueExpressionPrimary, but all the obvious ones were fine.
I did notice that the following did not parse:
select v from t where TRIM(v) = TRIM(c)
where other similar statements such as:
select v from t where TRIM(v) = c
select v from t where v = TRIM(LEADING FROM c)
parsed ok. I haven't looked at it any further than throwing a bunch of
different statements at it, this might be something to come back and
investigate at a later date.
> 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,
> compile_error.jj, sqlgrammar.jj.diff
>
>
> 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.
