Bug #26238 inserted delayed always inserts 0 for BIT columns

Description:
when using insert delayed statements which insert into a bit column, the bit is always 0.

mysql> drop table if exists mybit;
Query OK, 0 rows affected (0.00 sec)

mysql> create table mybit(a bit);
Query OK, 0 rows affected (0.05 sec)

mysql> insert into mybit values (1);
Query OK, 1 row affected (0.00 sec)

mysql> insert delayed into mybit values (1);
Query OK, 1 row affected (0.00 sec)

mysql> select hex(a) from mybit;
+--------+
| hex(a) |
+--------+
| 1      |
| 0      |
+--------+
2 rows in set (0.00 sec)

How to repeat:
delimiter ;
drop table if exists mybit;
create table mybit(a bit);
insert into mybit values (1);
insert delayed into mybit values (1);
select hex(a) from mybit;

Suggested fix:
insert the value told to insert

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/20780

ChangeSet@1.2418, 2007-02-28 18:34:35+04:00, svoj@mysql.com +3 -0
  BUG#26238 - inserted delayed always inserts 0 for BIT columns
  
  INSERT DELAYED inserts garbage for BIT columns.
  
  When delayed thread clones TABLE object, it didn't adjusted bit_ptr
  to newly created record (though it correctly adjusts ptr and null_ptr).
  
  This is fixed by correctly adjusting bit_ptr when performing a clone.
  With this fix BIT values are stored correctly by INSERT DELAYED.

This seems to be (almost) a backport from 5.1. However in 5.1 we use a slightly different method for the same purpose. I approve the patch. But please do a null-merge to 5.1.

Switched to "In review" for Ramil, btw.

Fixed in 5.0.38, 5.1.17.

Noted in 5.0.38, 5.1.17 changelogs.