Ø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
signature.asc
Description: OpenPGP digital signature
