Patch for Bug#50511 (Sometimes wrong handling of user variables containing NULL).

      
The bug happened under the following condition:
  - there was a user variable of type REAL, containing NULL value
  - there was a table with a NOT_NULL column of any type but REAL, having
    default value (or auto increment);
  - a row was inserted into the table with the user variable as value.
    A warning was emitted here.

The problem was that handling of NULL values of REAL type was not properly
implemented: it didn't expect that REAL NULL value can be assigned to other
data type.

Basically, the problem was that set_field_to_null() was used instead of
set_field_to_null_with_conversions().

The fix is to use the right function, or more generally, to allow conversion of
REAL NULL values to other data types.

1 files changed, 31 insertions, 0 deletions

diff --git a/mysql-test/r/user_var.result b/mysql-test/r/user_var.result
index c73d2e64540..29c05a60166 100644
--- a/mysql-test/r/user_var.result
+++ b/mysql-test/r/user_var.result
@@ -429,3 +429,34 @@ INSERT INTO t1 VALUES (1);
 INSERT INTO t1 VALUES (1);
 DROP TABLE t1;
 End of 5.1 tests
+DROP TABLE IF EXISTS t1;
+CREATE TABLE t1(f1 INT AUTO_INCREMENT, PRIMARY KEY(f1));
+INSERT INTO t1 SET f1 = NULL ;
+SET @aux = NULL ;
+INSERT INTO t1 SET f1 = @aux ;
+SET @aux1 = 0.123E-1;
+SET @aux1 = NULL;
+INSERT INTO t1 SET f1 = @aux1 ;
+SELECT * FROM t1;
+f1
+1
+2
+3
+DROP TABLE t1;
+CREATE TABLE t1(f1 VARCHAR(257) , f2 INT, PRIMARY KEY(f2));
+CREATE TRIGGER trg1 BEFORE INSERT ON t1 FOR EACH ROW SET @aux = 1;
+SET @aux = 1;
+SET @aux = NULL;
+INSERT INTO test.t1 (f1, f2) VALUES (1, 1), (@aux, 2);
+SET @aux = 'text';
+SET @aux = NULL;
+INSERT INTO t1(f1, f2) VALUES (1, 3), (@aux, 4);
+SELECT f1, f2 FROM t1 ORDER BY f2;
+f1	f2
+1	1
+1	2
+1	3
+1	4
+DROP TRIGGER trg1;
+DROP TABLE t1;
+End of 5.5 tests