Should UCS_BASIC character types have to look at collation elements when dealing with escape character in the LIKE clause?

• Key: DERBY-3315
• Type: Task
• Status: Resolved
• Resolution: Fixed
• Priority: Major
• Assignee: Mamta A. Satoor
• Reporter: Mamta A. Satoor
• Component/s: JDBC
• Affects Version/s: 10.3.1.4, 10.3.2.1, 10.4.1.3
• Fix Version/s: 10.3.3.0, 10.4.1.3

Description

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

Comments

[Daniel John Debrunner]

I would say the check is just wrong. Why does the number of collation elements for an escape character need to be one?

The escape character is there to escape special characters, it has nothing to do with collation.

[Mamta A. Satoor]

I have removed the code mentioned above while removing the disabled national character code. The changes went in as part of revision 612525 into trunk. I will port these changes into 10.3 too.

Merged changes from trunk(612525) into 10.3 codeline(revision 612576).