db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: [jira] Updated: (DERBY-1862) Simple hash improves performance
Date Mon, 18 Sep 2006 15:57:52 GMT
Andreas Korneliussen wrote:

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

No, see below.

> 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 think the changes were made to use a single locale (English) for the
SQL language so that Derby would work in Turkish. Having the name
matching in SQL be dependent on the locale of the client or engine would
mean that the potential exists for a SQL statement from a single
application to have different meanings in different locales. That is not
the expected behaviour when working against a programming language.

When the SQL parser upper cased items in the engine's locale an
application using 'insert' would fail in Turkish, as it does not upper
case to "INSERT".

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

I think because String.equalsIgnoreCase() is dependent on the current


View raw message