On Sat, 2005-03-19 at 18:26 +0100, Martijn Tonies wrote:

>
>
> > The computerized world is constantly moving towards support for
> > nationalization. Unicode is spreading. You can now actually use national
> > characters in domain names (but you have to back them up with plain
> > ASCII versions due to old browsers etc.). Most applications that target
> > "normal users" have nationalized versions. Even Delphi comes in three
> > language versions and that's a development too.
> >
> > Why should SQL stay behind?
>
> Well... for one...
>
> In SQL Server, there was this system table INDEXES. It was
> defined as "indexes". Guess what happens on a server with a
> Turkish collation as the server wide collation?
>
> indexes uppercased becomes ÍNDEXES because the small
> character "i" becomes "Í" and not "I".
>
> Now, this means that every metadata name, although defined
> as "indexes" (no quotes, not case sensitive) might get messed
> up because of national crap.
>
> I say - yet another good reason to keep it to simple ASCII :-D
>

I would say that this is a case for moving to UTF-8. That way, there is
never any ambiguity. Each piece of "national crap" has its own
datapoint that is universally understood and is distinct.

For what it's worth, I set up some test cases last week using FB 1.5.2
under linux. FB 1.5.2 correctly stores, retrieves, and indexes on UTF-8
when the characters are stored using "no character set". I tested with
English, French, Arabic, Chinese, and Hindi characters in the same
column of a test table.

An interesting effect was that ISQL displayed the national characters
correctly, even to the point of correctly reversing the display of the
arabic text so it could be read from right to left.

The only "gotchas" are that Firebird does not distinguish between
character length and byte length of a string yet (I believe that the
international branch is working on this), and only binary collation is
supported. For my apps, this is not a big issue.

UTF8 support is already mostly there.