db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Assigned: (DERBY-1386) Wrong results with query using LIKE and ESCAPE clause that includes "%", "\", and "_"
Date Thu, 08 Jun 2006 12:31:31 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1386?page=all ]

Knut Anders Hatlen reassigned DERBY-1386:
-----------------------------------------

    Assign To: Knut Anders Hatlen

There is a bug in the unoptimized version of
Like.lessThanString(). The bug was not introduced by DERBY-1262, just
exposed by it. I will try to fix it in trunk and 10.1.

lessThanString() searches for the first occurrence of % or _ in the
pattern string, and if the preceding character is an escape character,
it is skipped. This leads to incorrect behaviour when % or _ is
preceded by an escaped escape character.

> Wrong results with query using LIKE and ESCAPE clause that includes "%", "\", and "_"
> -------------------------------------------------------------------------------------
>
>          Key: DERBY-1386
>          URL: http://issues.apache.org/jira/browse/DERBY-1386
>      Project: Derby
>         Type: Bug

>     Versions: 10.2.0.0, 10.1.2.5
>     Reporter: A B
>     Assignee: Knut Anders Hatlen
>     Priority: Critical

>
> After the fix for DERBY-1262 was checked in, I'm noticing that the following query now
returns different results.  Prior to the fix for DERBY-1262 the query returned 2 rows; now
it doesn't return any rows.
> create table escTable (c1 char(10));
> insert into escTable values ('%_\a');
> insert into escTable values ('%_b');
> insert into escTable values ('%c');
> insert into escTable values ('d');
> insert into escTable values ('%_\e');
> select c1 from escTable where c1 like '\%\_\\%' ESCAPE '\';
> Before DERBY-1262, the SELECT returned:
> C1
> ----------
> %_\a
> %_\e
> 2 rows selected
> Now it returns:
> C1
> ----------
> 0 rows selected
> Brief inspection of the query and data suggest to me that these new results (i.e. no
rows) are wrong, and that Derby should in fact return 2 rows/.
> Based on comments in DERBY-1262, I'm creating a new Jira issue for the regression since
it has been checked into the 10.1 maintenance branch.  I've set the priority to "Critical"
since this could potentially delay a 10.1.3 release--I.e. I don't think we'd want to release
10.1.3 knowing that we have a wrong results regression.  But if anyone thinks that's not the
correct priority, feel free to speak up.
> Other option, of course, is to back out the change for DERBY-1262 in 10.1 and then lower
the priority accordingly.  
> Input/feedback/comments would be appreciated.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message