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] Commented: (DERBY-1386) Wrong results with query using LIKE and ESCAPE clause that includes "%", "\", and "_"
Date Thu, 08 Jun 2006 11:28:30 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1386?page=comments#action_12415324 ] 

Knut Anders Hatlen commented on DERBY-1386:
-------------------------------------------

I see the same results. However, when I use like to test the same values as constants, it
correctly evaluates to true:

ij> select * from sysibm.sysdummy1 where '%_\a' like '\%\_\\%' escape '\';
IBM&
----
Y   

1 row selected

> 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
>     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