db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@apache.org>
Subject [jira] Created: (DERBY-3315) Should UCS_BASIC character types have to look at collation elements when dealing with escape character in the LIKE clause?
Date Fri, 11 Jan 2008 06:09:34 GMT
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.2.1, 10.3.1.4, 10.4.0.0
            Reporter: 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.


Mime
View raw message