Bug#12976 (stored procedures local variables of type bit)

Before this change, a local variables in stored procedures / stored functions
or triggers, when declared with a type of bit(N), would not evaluate their
value properly.

The problem was that the data was incorrectly typed as a string,
causing for example bit b'1', implemented as a byte 0x01, to be interpreted
as a string starting with the character 0x01. This later would cause
implicit conversions to integers or booleans to fail.

The root cause of this problem was an incorrect translation between field
types, like bit(N), and internal types used when representing values in Item
objects.

Also, before this change, the function HEX() would sometime print extra "0"
characters when invoked with bit(N) values.

With this fix, the type translation (sp_map_result_type, sp_map_item_type)
has been changed so that bit(N) fields are represented with integer values.

A consequence is that, for the function HEX(), when called with a stored
procedure local variable of type bit(N) as argument, HEX() is provided with an
integer instead of a string, and therefore does not print "0" padding.

A test case for Bug 12976 was present in the test suite, and has been updated.


mysql-test/r/sp-vars.result:
  Local stored procedure variables of type bit(N) are integer values.
mysql-test/t/sp-vars.test:
  Local stored procedure variables of type bit(N) are integer values.
sql/sp_head.cc:
  Local stored procedure variables of type bit(N) are integer values.

1 files changed, 58 insertions, 7 deletions

diff --git a/mysql-test/t/sp-vars.test b/mysql-test/t/sp-vars.test
index 7cf92dc5d0d..0014dc1f6af 100644
--- a/mysql-test/t/sp-vars.test
+++ b/mysql-test/t/sp-vars.test
@@ -500,8 +500,6 @@ DROP PROCEDURE p1;
 #
 # Test case for BUG#12976: Boolean values reversed in stored procedures?
 #
-# TODO: test case failed.
-#
 ###########################################################################
 
 --echo
@@ -566,13 +564,8 @@ BEGIN
 END|
 delimiter ;|
 
-# The expected and correct result.
-
 call p1();
 
-# The wrong result. Note that only hex(vb) works, but is printed with two
-# digits for some reason in this case.
-
 call p2();
 
 #
@@ -583,6 +576,64 @@ DROP TABLE t1;
 DROP PROCEDURE p1;
 DROP PROCEDURE p2;
 
+# Additional tests for Bug#12976
+
+--disable_warnings
+DROP TABLE IF EXISTS table_12976_a;
+DROP TABLE IF EXISTS table_12976_b;
+DROP PROCEDURE IF EXISTS proc_12976_a;
+DROP PROCEDURE IF EXISTS proc_12976_b;
+--enable_warnings
+
+CREATE TABLE table_12976_a (val bit(1));
+
+CREATE TABLE table_12976_b(
+  appname varchar(15),
+  emailperm bit not null default 1,
+  phoneperm bit not null default 0);
+
+insert into table_12976_b values ('A', b'1', b'1'), ('B', b'0', b'0');
+
+delimiter ||;
+CREATE PROCEDURE proc_12976_a()
+BEGIN
+  declare localvar bit(1);
+  SELECT val INTO localvar FROM table_12976_a;
+  SELECT coalesce(localvar, 1)+1, coalesce(val, 1)+1 FROM table_12976_a;
+END||
+
+CREATE PROCEDURE proc_12976_b(
+  name varchar(15),
+  out ep bit,
+  out msg varchar(10))
+BEGIN
+  SELECT emailperm into ep FROM table_12976_b where (appname = name);
+  IF ep is true THEN
+    SET msg = 'True';
+  ELSE
+    SET msg = 'False';
+  END IF;
+END||
+
+delimiter ;||
+
+INSERT table_12976_a VALUES (0);
+call proc_12976_a();
+UPDATE table_12976_a set val=1;
+call proc_12976_a();
+
+call proc_12976_b('A', @ep, @msg);
+select @ep, @msg;
+
+call proc_12976_b('B', @ep, @msg);
+select @ep, @msg;
+
+DROP TABLE table_12976_a;
+DROP TABLE table_12976_b;
+DROP PROCEDURE proc_12976_a;
+DROP PROCEDURE proc_12976_b;
+
+
 ###########################################################################
 #
 # Test case for BUG#9572: Stored procedures: variable type declarations