[
http://issues.apache.org/jira/browse/DERBY-1262?page=comments#action_12377762 ]
Håvard Mork commented on DERBY-1262:
------------------------------------
I believe this is a duplicate of DERBY-20.
This behaviour is due to the optimization of LikeEscapeOperatorNode. This node
is converted to less-than and greater-than expressions ("abc" < column < "abd"
) that are sent to the scan controller through 'qualifier' objects. When these
are evaluated with SQLChar.stringCompare, the shorter string is padded with
spaces, and the comparison fail due to that the ordinal value of TAB is less
than Space. The comparison is correct, but optimization probably not.
> Like-predicates: % does not match tab character
> -----------------------------------------------
>
> Key: DERBY-1262
> URL: http://issues.apache.org/jira/browse/DERBY-1262
> Project: Derby
> Type: Bug
> Components: SQL
> Versions: 10.0.2.0
> Environment: Embedded, Solaris 10 x86
> Reporter: Øystein Grøvlen
>
> % in like predicates does not seem to match tab character. In the following
> example all whitespace in character literals is the tab character:
> ij> create table t4(i integer primary key, j integer, c varchar(10));
> 0 rows inserted/updated/deleted
> ij> insert into t4 values (1, 1, 'abc def');
> 1 row inserted/updated/deleted
> ij> select * from t4 where c like 'abc%';
> I |J |C
> ----------------------------------
> 0 rows selected
> ij> select * from t4 where c like 'abc %';
> I |J |C
> ----------------------------------
> 1 |1 |abc def
> 1 row selected
--
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
