[
https://issues.apache.org/jira/browse/DERBY-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511296
]
Mamta A. Satoor commented on DERBY-2793:
----------------------------------------
Dan's last comment on July 5th had this question "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)? " We have jira entry for this
issue DERBY-2725 ( If all the operands involved in collation operation have a
collation derivation of NONE, then Derby should throw an exception for that as
per the SQL standards.) and it was fixed on July 6th. After this fix, now we
have a behavior which is sub-set of the SQL standard.
As for Dan's another remark "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? " I haven't spent
enough time to be able to visualize a problem with existing
applications/databases. Dan, do you have some examples in mind which shows how
the existing application might get impacted? The only way one can run into
colllation derivation of NONE is if character string types of different
collation types are involved in operations like CONCAT, COALESCE, NULLIF etc.
But since existing applications/databases will all always have the same
collation type which is UCS_BASIC, at this point, I can't see how they might
get affected?
> 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.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.
