Fabricio Araujo wrote:

>Internacionalization
>====================
> Keep the limitation until you can do it in a way that not disrupt
> existing applications. ASCII char/varchar fields must continue
> work as always, the same way as performance of server under normal
> Load - not to talk on reliability. No documented behavior must be
> broken unless all alternatives are dismissed.

Backwards compatibility is important, but to my knowledge I haven't
suggested anything that would break that. If I'm wrong, please give me a
quote - I want to see what I wrote...

What I want is:

1. Unquoted identifiers remain case insensitive and support only plain 7
bit ASCII. I.e. no change.

2. Quoted identifiers should be (and are already) case sensitive and
support national characters. What's new is here that all bugs in this
area should be removed, in FB itself and in client tools etc. This would
not break backwards compatibility - it would simply make life easier for
those of us who want to use this new feature to its full extent.

> Progress costs money. Brazil is not Sweden. Many customers of FB
> developers still have 10MBit networks and network traffic is, yes,
> a issue. Some even cannot spare a computer to be a db server,
> sharing it with printers, file shares, etc.

I would expect the rate of progress in these areas to be at least as
high in Brazil as in Sweden, since you're (hopefully) catching up while
we're lagging behind. And in that case the performance impacts of a
change will actually, relatively speaking, hit us harder up here.

But I accept that you do have a point. I'm just not sure if performance
would really be affected. Maybe it would even improve, because without
case conversion etc. the server actually has less work to do. If I'm not
mistaken, identifiers are already stored in UTF-8, so there wouldn't be
any change in storage size.

>Case sensitive identifiers
>==========================
> If for a case mistake a entire system could disrupt or
> behave wrongly

...then you need to work on your test procedures and QA. Such a simple
mistake should be caught before going into production. It's no different
from any other kind of typo, for example m instead of n, which is also
difficult to spot in most fonts, and certainly harder to spot than for
example R vs. r.

Kjell
--
--------------------------------------
Kjell Rilbe
Adressmarknaden AM AB
E-post: kjell.rilbe@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64