On 11/06/2010 08:43, Dimitry Sibiryakov wrote:

> 11.06.2010 13:36, Adriano dos Santos Fernandes wrote:
>
>> On 11/06/2010 08:30, Dimitry Sibiryakov wrote:
>>
>>> Currently data in character set OCTETS are assigned to
>>> variables/fields as-is, which in combination with check for malformed
>>> string makes such assignments unpredictable and thus useless.
>>>
>>>
>> Justify, please. It seems the only problem is that it doesn't work the
>> way you want.
>>
> If I write logging trigger, I write something like that:
> INSERT INTO log_table (Key_value) VALUES (NEW.id);
> If Key_value field has character set different from OCTETS while id
> has OCTETS, this construction may work or fail depending on value of id.
> I.e. it behaves unpredictable.
>
>

Then use OCTETS.

What about you propose, then you will ask to key_value accept it length
multiplied by two because the octets field has been converted to hex string.

>>> I suggest to follow Oracle in this regard and convert binary data to
>>> hexadecimal string.
>>>
>>>
>> And break any application that expect things as working now. Why?
>>
> Do you know any application that expects behavior described above,
> i.e random errors?..
>
>

The random part here is your code, sorry.

>> It just works different. There is no problem with current functionality.
>> It's not unpredictable in any way!
>>
> It is predictable if you can predict target character set and exact
> assigned value. My crystal ball is not good enough for such things.
>

If you want to store string originally encoded in multiple character
sets in a field, you'd better use OCTETS.


Adriano