[
https://issues.apache.org/jira/browse/DERBY-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mamta A. Satoor reassigned DERBY-3315:
--------------------------------------
Assignee: Mamta A. Satoor
> Should UCS_BASIC character types have to look at collation elements when
> dealing with escape character in the LIKE clause?
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3315
> URL: https://issues.apache.org/jira/browse/DERBY-3315
> Project: Derby
> Issue Type: Task
> Components: JDBC
> Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0
> Reporter: Mamta A. Satoor
> Assignee: Mamta A. Satoor
>
> Code in SQLChar.like(dvd, dvd) method at line number 1767 is executed for
> non-national/non-collation sensitive character types ie for UCS_BASIC
> character types and the code looks as follows
> // Make sure we fail for both varchar an nvarchar
> // for multiple collation characters.
> SQLChar escapeSQLChar = (SQLChar) escape;
> int[] escapeIntArray = escapeSQLChar.getIntArray();
> if (escapeIntArray != null && (escapeIntArray.length != 1))
> {
> throw
> StandardException.newException(SQLState.LANG_INVALID_ESCAPE_CHARACTER,new
> String (escapeSQLChar.getCharArray()));
> }
> It appears that we are trying to see if number of collation elements
> associated with escape character is more than 1 and if yes, then we throw
> exception. Seems like a code like above should be done for collation
> sensitive character types and not for UCS_BASIC character types.
> Interestingly, nothing like this is getting checked for national character
> datatypes.
> This behavior was detected while working on DERBY-3302
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
