You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Shreyas Kaushik (JIRA)" <de...@db.apache.org> on 2005/02/03 06:42:17 UTC
[jira] Commented: (DERBY-20) LIKE handles strings with control characters incorrectly.
[ http://issues.apache.org/jira/browse/DERBY-20?page=comments#action_58547 ]
Shreyas Kaushik commented on DERBY-20:
--------------------------------------
A more clear comment here would be useful.
Clear meaning, what is the use case that you are talking about here? A small example of the behaviour with expcted output vs. current output would help.
> LIKE handles strings with control characters incorrectly.
> ---------------------------------------------------------
>
> Key: DERBY-20
> URL: http://issues.apache.org/jira/browse/DERBY-20
> Project: Derby
> Type: Bug
> Components: SQL
> Versions: 10.0.2.0
> Reporter: Tulika Agrawal
> Priority: Minor
>
> Reporting for Daniel John Debrunner.
> If a string contains control characters in the regions matched
> by wild card characters then in some situations a LIKE will
> return false instead of true and the row will not be returned.
> Caused by the dynamic like optimization using >= with a prefix
> which is is equivalent to >= on the prefeix appended with
> blanks and not null (\u0000) characters.
--
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-20) LIKE handles strings with control
characters incorrectly.
Posted by Shreyas Kaushik <Sh...@Sun.COM>.
Updates ?
~ Shreyas
Shreyas Kaushik wrote:
> Any updates here?
>
> ~ Shreyas
>
> Shreyas Kaushik (JIRA) wrote:
>
>> [
>> http://issues.apache.org/jira/browse/DERBY-20?page=comments#action_58547
>> ]
>> Shreyas Kaushik commented on DERBY-20:
>> --------------------------------------
>>
>> A more clear comment here would be useful.
>>
>> Clear meaning, what is the use case that you are talking about here?
>> A small example of the behaviour with expcted output vs. current
>> output would help.
>>
>>
>>
>>> LIKE handles strings with control characters incorrectly.
>>> ---------------------------------------------------------
>>>
>>> Key: DERBY-20
>>> URL: http://issues.apache.org/jira/browse/DERBY-20
>>> Project: Derby
>>> Type: Bug
>>> Components: SQL
>>> Versions: 10.0.2.0
>>> Reporter: Tulika Agrawal
>>> Priority: Minor
>>>
>>
>>
>>
>>
>>> Reporting for Daniel John Debrunner.
>>> If a string contains control characters in the regions matched by
>>> wild card characters then in some situations a LIKE will return
>>> false instead of true and the row will not be returned.
>>> Caused by the dynamic like optimization using >= with a prefix which
>>> is is equivalent to >= on the prefeix appended with blanks and not
>>> null (\u0000) characters.
>>>
>>
>>
>>
>>
Re: [jira] Commented: (DERBY-20) LIKE handles strings with control
characters incorrectly.
Posted by Shreyas Kaushik <Sh...@Sun.COM>.
Any updates here?
~ Shreyas
Shreyas Kaushik (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-20?page=comments#action_58547 ]
>
>Shreyas Kaushik commented on DERBY-20:
>--------------------------------------
>
>A more clear comment here would be useful.
>
>Clear meaning, what is the use case that you are talking about here? A small example of the behaviour with expcted output vs. current output would help.
>
>
>
>>LIKE handles strings with control characters incorrectly.
>>---------------------------------------------------------
>>
>> Key: DERBY-20
>> URL: http://issues.apache.org/jira/browse/DERBY-20
>> Project: Derby
>> Type: Bug
>> Components: SQL
>> Versions: 10.0.2.0
>> Reporter: Tulika Agrawal
>> Priority: Minor
>>
>>
>
>
>
>>Reporting for Daniel John Debrunner.
>>If a string contains control characters in the regions matched
>>by wild card characters then in some situations a LIKE will
>>return false instead of true and the row will not be returned.
>>Caused by the dynamic like optimization using >= with a prefix
>>which is is equivalent to >= on the prefeix appended with
>>blanks and not null (\u0000) characters.
>>
>>
>
>
>