database/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-07-30 16:24:05 +03:00
Code Activity

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

Browse Source 
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.
This commit is contained in:
Alexander Nozdrin
2010-05-05 15:00:59 +04:00
parent 3c93a784d4
commit 0a032dea1f
4 changed files with 74 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
mysql-test/r/user_var.result
View File

@ -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