[ http://issues.apache.org/jira/browse/DERBY-1386?page=comments#action_12415568 ]
A B commented on DERBY-1386: ---------------------------- I reviewed this patch and the changes look correct to me. The old code matches the problem that Knut identified and the new code addresses the issues and does what is described in the previous comment. I also verified that the repro passes with the patch applied, and that the new test cases fail without the patch and pass with it. I haven't run derbyall myself but since Knut ran it and said everything passed, I vote +1 to have this committed. Thanks again for volunteering to address this, Knut, and for doing it so quickly. > 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 > Attachments: derby-1386-v1.diff, derby-1386-v1.stat > > 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
