Dimitry Sibiryakov wrote:

>On 28 Feb 2005 at 23:56, Adriano dos Santos Fernandes wrote:
>
>
>
>>For *all* current FB users (who that don't depent on broken
>>UNICODE_FSS) will cause these problems:
>>
>>1) Slow (because conversions will always be made).
>>
>>
>
> Once upon a time I tried to trace FB engine. I was really
>astonished how many conversions (INTL module invocation) was
>performed.
>
>

The problem is that modules preprocessed with gpre_static is incorrectly
using blr_cstring, blr_varying and blr_text instead of blr_cstring2,
blr_varying2 and blr_text2 with value 3 (UNICODE_FSS).

This means that the engine ask for metadata fields and the engine
incorrectly convert from UNICODE_FSS to the connection charset instead
of leave the data using UNICODE_FSS.

>
>
>>2) Break all UDFs that use strings.
>>3) Break all external tables.
>>
>>
>
> Nope if EXT module perform conversion to/from character set which
>they were declared with.
>
>

Well, charsets in the client and in special locations of the server will
be a very bad idea.
This make clear that the proposal has drastic changed because people has
not think about this.

>
>
>>4) Don't simplify the engine because conversions between charsets is
>>done like conversions between numbers and strings.
>>
>>
>
> Conversion into certain data charset is required only when data
>leave engine.
>
>

This is very abstract. When data leave the engine? What is all these places?

>
>
>>5) Waste of disk space and memory.
>>
>>
>
> That's the only weighty argument.
>
>

And waste of network band.


Adriano