db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Korneliussen <Andreas.Kornelius...@Sun.COM>
Subject Re: [jira] Updated: (DERBY-1862) Simple hash improves performance
Date Mon, 18 Sep 2006 14:20:57 GMT
Øystein Grøvlen wrote:
> Andreas Korneliussen (JIRA) wrote:
> 
>> String.toUpperCase(..) with english locale, should return a string
>> with the same number of characters, and it should therefore be valid
>> to do a check of number of characters before doing any conversions.
> 
> Is it correct to always use English locale in this case?  Ref the
> reference guide on SQL identifiers:
> 
>       An ordinary identifier must begin with a letter and contain
>       only letters, underscore characters (_), and digits. The
>       permitted letters and digits include all Unicode letters and
>       digits, but Derby does not attempt to ensure that the
>       characters in identifiers are valid in the database's
>       locale.
> 
> Should not it be possible to match column names in any locale?
> 

Your question is a valid question to ask about this method, however my
intention was to make the method keep its current behavior. The patch
simply preserves the current behaviour (which is to use english locale).
So any sets of strings s1 and s2 should make the method return the same
values as before the patch. If this is not the case, the patch is not as
intended.

When looking deeper into the String class, my understanding is that the
only Locale which has different semantics than other Locales when it
comes to toUpperCase(Locale..), is Turkish, so maybe Derby does not work
correctly in Turkish locale.

I also wondered why Derby has its own SQLIgnoreCase method, instead of
simply using String.equalsIgnoreCase(). The Derby implementation is very
inefficient compared to the String.equalsIgnoreCase() method, since you
risk creating two new string objects before doing the comparison.

Andreas


> -- 
> Øystein



Mime
View raw message