[
https://issues.apache.org/jira/browse/DERBY-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510447
]
Daniel John Debrunner commented on DERBY-2793:
----------------------------------------------
The description for this issue says the collation for LIKE should match the SQL
standard. The latest change does not match the SQL standard, thus I don't think
it should be closed. I didn't know that those other bugs existed, after reading
them I think that the current collation determination is not a sub-set of the
SQL standard. That is some comparisions allowed by the current code will not be
allowed once collation determination correctly follows 9.13.
A sub-set of the SQL standard would seem fine, as a work in progress. That is
all comparisions that are allowed by Derby are also allowed by the SQL
standard, but Derby may not support comparisions (throws exception at compile
time) that the SQL standard supports. But I don't think that's where the code
is at the moment.
One case is that if the derivation is NONE for all operands of the comparision
operator then the current code would seem to allow collation, but 9.13 expects
a '42' error to be raised. Allowing a release with this may have backwards
compatibility issues, SQL statements that incorrectly worked will fail.
Wouldn't it be simple to add a check that at least one of the operands have
the derivation IMPLICIT or EXPLICIT (in addition to the existing tests)?
I also wonder if fixing the collation determination to be correct (9.13 based)
will affect existing applications/databases, those with collation=UCS_BASIC.
Will there be some comparisons that will (correctly) not be supported anymore?
> Ensure LIKE predicate follows correct rules for determing collation
> -------------------------------------------------------------------
>
> Key: DERBY-2793
> URL: https://issues.apache.org/jira/browse/DERBY-2793
> Project: Derby
> Issue Type: Sub-task
> Components: SQL
> Reporter: Daniel John Debrunner
> Assignee: Mamta A. Satoor
> Fix For: 10.3.1.1, 10.4.0.0
>
>
> The current code in LikeEscapeOperatorNode seems to only check that the
> collations are identical. That is not the correct mechanism for determing
> collation which is based upon SQL spec Section 9.13 "Collation determination"
> or item 12 in the DERBY-1478 wiki page.
> http://wiki.apache.org/db-derby/BuiltInLanguageBasedOrderingDERBY-1478
> I think it's also essential that the (somewhat complex) logic to implement
> collation determination is in a single method, not repeated multiple times
> for each collation.
> There is a TODO in LikeEscapeOperatorNode that might be related to this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
