Bug #2368 Multibyte charsets do not check that incoming data is well-formed

• Submitted: 13 Jan 2004 5:44
• Modified: 10 Feb 2004 5:41
• Reporter: Alexander Barkov
• Status: Closed
• Category: MySQL Server
• Severity: S3 (Non-critical)
• Version: 4.1.2-bk-current
• Assigned to: Alexander Barkov
• CPU Architecture: Any

[13 Jan 2004 5:44] Alexander Barkov

Description:
mysql> create table t1 (a nchar(10));
Query OK, 0 rows affected (0.01 sec)

mysql> insert into t1 values (0xFF);
Query OK, 1 row affected (2.20 sec)

mysql> select *,hex(a) from t1;
+------+--------+
| a    | hex(a) |
+------+--------+
| ?    | FF     |
+------+--------+
1 row in set (0.01 sec)

This is wrong behaviour. We should not store non-well-formed
values into fields. 

How to repeat:
Run the above example.

Suggested fix:
The question is what should we do instead?
A. Cut well-formed beginning?
B. Or insert a NULL value instead?

[22 Jan 2004 4:45] Alexander Barkov

This is IRC conversation log on Jan 15:

<bar>   monty: how do you think should we accept inserts
        into multibyte columns if the incoming data is not well-formed?
<bar>   should we cut a well-formed beginning?
<bar>   or should we insert as-is without checking?
<bar>   or should we produce an error?
<monty> We should at least give a warning
<monty> It's better to only have well-formed data as
        otherwise you have to do a lot of extra
        checking in all other places
<bar>   Probably we should cut a well-formed beginning then.
<monty> yes

[10 Feb 2004 5:41] Alexander Barkov

Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at
    http://www.mysql.com/doc/en/Installing_source_tree.html