On Wed, 23 Mar 2005 10:15:54 +0100, Kjell Rilbe wrote:

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

I agree... But internacionalization effort is being done, but
as I saw in devel list... The hole is lower...
Maybe it solves your problem in one shot, because system tables
will certainly be affected.

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

New networks are being made in 100Mbit, but older ones are only
changed when there is a very strong point to the company.
Otherwise, stay 10Mbit.
Anyway, any increase in net traffic will affect application that
connect FB over Internet, which are already troubled by the normal
traffic of FB - because of it and for security reasons, tunneling
software is
becoming a common advice amongst the community, such as ZebeDee
or Stunnel

What I fear is that impact could be shared among all, have or not the
problem of additional chars in language.

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

Yeah... But UNICODE_FSS and internationalizaton is a very troubled
issue discussed to dismay here, architect and devel lists.

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

Most developers here work on a one-man-house basis, Kjell. So not
looking
for trouble is better... ;-)

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

1) But r vc R are mostly subtle and lead to logical errors.
2) n vs M mostly generate SP or code compiling error.

Debug time for 1) is MUCH higher than 2).

In a case-insensitive system, 1) is harmless. So, ripped out a source
of obscure bugs. Sometimes is this a difference between a night of
sleep on your bed or a sleepless night fighting debug issues.