2006-12-22 00:38:34 +01:00
|
|
|
# This test uses chmod, can't be run with root permissions
|
|
|
|
-- source include/not_as_root.inc
|
|
|
|
|
|
|
|
|
2003-01-06 00:48:59 +01:00
|
|
|
# Initialise
|
|
|
|
--disable_warnings
|
|
|
|
drop table if exists t1;
|
|
|
|
--enable_warnings
|
|
|
|
|
2000-12-28 02:56:38 +01:00
|
|
|
#
|
|
|
|
# varbinary as string and number
|
|
|
|
#
|
|
|
|
|
|
|
|
select 0x41,0x41+0,0x41 | 0x7fffffffffffffff | 0,0xffffffffffffffff | 0 ;
|
|
|
|
select 0x31+1,concat(0x31)+1,-0xf;
|
The bug
MDEV-4489 "Replication of big5, cp932, gbk, sjis strings makes wrong values on slave"
has been fixed.
Problem:
String constants of some Asian charsets (big5,cp932,gbk,sjis)
can have backslash '\' (0x5C) in the second byte of multi-byte characters.
Replicating of such constants using the standard '\'-escaping is dangerous.
Therefore, constants of these charsets are replicated using hex notation:
INSERT INTO t1 (a) VALUES (0x815C);
However, 0xHHHH constants do not work well in some cases,
because they can behave as strings and as numbers, depending on context
(for example, depending on the data type of the column in an INSERT statement).
This SQL script was not replicated correctly with statement-based replication:
SET NAMES gbk;
PREPARE STMT FROM 'INSERT INTO t1 (a) VALUES (?)';
SET @a = '1';
EXECUTE STMT USING @a;
The INSERT statement was replicated as:
INSERT INTO t1 (a) VALUES (0x31);
'1' was correctly converted to the number 1 on master.
But the 0x31 constant was treated as number 49 on slave.
Fix:
1. Binary log now uses X'HHHH' instead of 0xHHHH constants.
2. The X'HHHH' constants now work always as strings, in all contexts.
This is the SQL standard compliant behaviour.
After the fix, the above statement is replicated as:
INSERT INTO t1 (a) VALUES (X'31');
X'31' is treated as string '1' on slave, and is correctly converted to 1.
modified:
@ mysql-test/r/ctype_cp932_binlog_stm.result
@ mysql-test/r/select.result
@ mysql-test/r/select_jcl6.result
@ mysql-test/r/select_pkeycache.result
@ mysql-test/r/user_var-binlog.result
@ mysql-test/r/varbinary.result
@ mysql-test/suite/binlog/r/binlog_stm_ctype_ucs.result
@ mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result
@ mysql-test/suite/rpl/r/rpl_charset_sjis.result
@ mysql-test/suite/rpl/r/rpl_mdev382.result
@ mysql-test/suite/rpl/t/rpl_charset_sjis.test
@ mysql-test/t/ctype_cp932_binlog_stm.test
@ mysql-test/t/select.test
@ mysql-test/t/varbinary.test
Adding and updating tests
@ sql/item.cc
@ sql/item.h
@ sql/sql_yacc.yy
@ sql/sql_lex.cc
Splitting the implementations of X'HH' and 0xHH constants into two
separate classes. Fixing the parser to distinguish the two syntaxes.
@ sql/log_event.cc
Using X'HH' instead of 0xHH for binary logging for string constants
of the "dangerous" charsets.
@ sql/sql_string.h
Adding a helped method String::append_hex().
2013-05-08 11:36:17 +02:00
|
|
|
select x'31',0xffff+0;
|
|
|
|
select X'FFFF'+0;
|
|
|
|
|
|
|
|
#
|
|
|
|
# Hex string vs hex hybrid
|
|
|
|
#
|
|
|
|
SELECT x'31'+0, 0x31+0;
|
|
|
|
SELECT x'31'+0.1e0, 0x31+0.1e0;
|
|
|
|
SELECT x'312E39'+0e0, 0x312E39+0e0;
|
|
|
|
SELECT CAST(x'31' AS SIGNED), CAST(0x31 AS SIGNED);
|
|
|
|
SELECT CAST(x'31' AS DECIMAL(10,1)), CAST(0x31 AS DECIMAL(10,1));
|
|
|
|
SELECT CAST(x'312E39' AS SIGNED), CAST(0x312E39 AS SIGNED);
|
|
|
|
SELECT CAST(x'312E39' AS DECIMAL(10,1)), CAST(0x312E39 AS DECIMAL(10,1));
|
|
|
|
EXPLAIN EXTENDED SELECT X'FFFF', 0xFFFF;
|
|
|
|
CREATE TABLE t1 (a int);
|
|
|
|
INSERT INTO t1 VALUES (X'31'),(0x31);
|
|
|
|
INSERT INTO t1 VALUES (X'312E39'),(0x312E39);
|
|
|
|
SELECT * FROM t1;
|
|
|
|
DROP TABLE t1;
|
|
|
|
CREATE TABLE t1 (a DECIMAL(10,1));
|
|
|
|
INSERT INTO t1 VALUES (X'31'),(0x31);
|
|
|
|
INSERT INTO t1 VALUES (X'312E39'),(0x312E39);
|
|
|
|
SELECT * FROM t1;
|
|
|
|
DROP TABLE t1;
|
2000-12-28 02:56:38 +01:00
|
|
|
|
|
|
|
#
|
|
|
|
# Test of hex constants in WHERE:
|
|
|
|
#
|
|
|
|
|
|
|
|
create table t1 (ID int(8) unsigned zerofill not null auto_increment,UNIQ bigint(21) unsigned zerofill not null,primary key (ID),unique (UNIQ) );
|
|
|
|
insert into t1 set UNIQ=0x38afba1d73e6a18a;
|
|
|
|
insert into t1 set UNIQ=123;
|
2003-10-30 11:57:26 +01:00
|
|
|
explain extended select * from t1 where UNIQ=0x38afba1d73e6a18a;
|
2000-12-28 02:56:38 +01:00
|
|
|
drop table t1;
|
2001-07-04 08:39:58 +02:00
|
|
|
|
|
|
|
#
|
|
|
|
# Test error conditions
|
|
|
|
#
|
|
|
|
--error 1064
|
|
|
|
select x'hello';
|
2001-07-10 14:53:08 +02:00
|
|
|
--error 1054
|
2001-07-04 08:39:58 +02:00
|
|
|
select 0xfg;
|
|
|
|
|
|
|
|
#
|
|
|
|
# Test likely error conditions
|
|
|
|
#
|
|
|
|
create table t1 select 1 as x, 2 as xx;
|
|
|
|
select x,xx from t1;
|
|
|
|
drop table t1;
|
2005-07-28 02:22:47 +02:00
|
|
|
|
|
|
|
# End of 4.1 tests
|
2006-11-09 12:00:27 +01:00
|
|
|
|
|
|
|
#
|
|
|
|
# Bug #19371 VARBINARY() have trailing zeros after upgrade from 4.1
|
|
|
|
#
|
|
|
|
|
|
|
|
# Test with a saved table from 4.1
|
2007-12-12 18:19:24 +01:00
|
|
|
let $MYSQLD_DATADIR= `select @@datadir`;
|
|
|
|
copy_file std_data/bug19371.frm $MYSQLD_DATADIR/test/t1.frm;
|
|
|
|
chmod 0777 $MYSQLD_DATADIR/test/t1.frm;
|
|
|
|
copy_file std_data/bug19371.MYD $MYSQLD_DATADIR/test/t1.MYD;
|
|
|
|
chmod 0777 $MYSQLD_DATADIR/test/t1.MYD;
|
|
|
|
copy_file std_data/bug19371.MYI $MYSQLD_DATADIR/test/t1.MYI;
|
|
|
|
chmod 0777 $MYSQLD_DATADIR/test/t1.MYI;
|
2006-11-09 12:00:27 +01:00
|
|
|
|
|
|
|
# Everything _looks_ fine
|
|
|
|
show create table t1;
|
|
|
|
|
|
|
|
# But the length of the varbinary columns are too long
|
|
|
|
select length(a), length(b) from t1;
|
|
|
|
|
|
|
|
# Run CHECK TABLE, it should indicate table need a REPAIR TABLE
|
|
|
|
CHECK TABLE t1 FOR UPGRADE;
|
|
|
|
|
|
|
|
# Run REPAIR TABLE to alter the table and repair
|
|
|
|
# the varbinary fields
|
|
|
|
REPAIR TABLE t1;
|
|
|
|
|
|
|
|
# Now check it's back to normal
|
|
|
|
show create table t1;
|
|
|
|
select length(a), length(b) from t1;
|
|
|
|
insert into t1 values("ccc", "ddd");
|
|
|
|
select length(a), length(b) from t1;
|
|
|
|
select hex(a), hex(b) from t1;
|
|
|
|
select concat("'", a, "'"), concat("'", b, "'") from t1;
|
|
|
|
|
|
|
|
drop table t1;
|
|
|
|
|
|
|
|
# Check that the fix does not affect table created with current version
|
|
|
|
create table t1(a varbinary(255));
|
|
|
|
insert into t1 values("aaa ");
|
|
|
|
select length(a) from t1;
|
|
|
|
alter table t1 modify a varchar(255);
|
|
|
|
select length(a) from t1;
|
2007-03-01 14:16:38 +01:00
|
|
|
drop table t1;
|
2006-11-09 12:00:27 +01:00
|
|
|
|
Bug#25411 (trigger code truncated), PART II
Bug 28127 (Some valid identifiers names are not parsed correctly)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
This patch is the second part of a major cleanup, required to fix
Bug 25411 (trigger code truncated).
The root cause of the issue stems from the function skip_rear_comments,
which was a work around to remove "extra" "*/" characters from the query
text, when parsing a query and reusing the text fragments to represent a
view, trigger, function or stored procedure.
The reason for this work around is that "special comments",
like /*!50002 XXX */, were not parsed properly, so that a query like:
AAA /*!50002 BBB */ CCC
would be seen by the parser as "AAA BBB */ CCC" when the current version
is greater or equal to 5.0.2
The root cause of this stems from how special comments are parsed.
Special comments are really out-of-bound text that appear inside a query,
that affects how the parser behave.
In nature, /*!50002 XXX */ in MySQL is similar to the C concept
of preprocessing :
#if VERSION >= 50002
XXX
#endif
Depending on the current VERSION of the server, either the special comment
should be expanded or it should be ignored, but in all cases the "text" of
the query should be re-written to strip the "/*!50002" and "*/" markers,
which does not belong to the SQL language itself.
Prior to this fix, these markers would leak into :
- the storage format for VIEW,
- the storage format for FUNCTION,
- the storage format for FUNCTION parameters, in mysql.proc (param_list),
- the storage format for PROCEDURE,
- the storage format for PROCEDURE parameters, in mysql.proc (param_list),
- the storage format for TRIGGER,
- the binary log used for replication.
In all cases, not only this cause format corruption, but also provide a vector
for dormant security issues, by allowing to tunnel code that will be activated
after an upgrade.
The proper solution is to deal with special comments strictly during parsing,
when accepting a query from the outside world.
Once a query is parsed and an object is created with a persistant
representation, this object should not arbitrarily mutate after an upgrade.
In short, special comments are a useful but limited feature for MYSQLdump,
when used at an *interface* level to facilitate import/export,
but bloating the server *internal* storage format is *not* the proper way
to deal with configuration management of the user logic.
With this fix:
- the Lex_input_stream class now acts as a comment pre-processor,
and either expands or ignore special comments on the fly.
- MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
public interface of Lex_input_stream. In particular, how the input stream
accepts or rejects a character is private to Lex_input_stream, and the
internal buffer pointers of that class are strictly private, and should not
be tempered with during parsing.
This caused many changes mostly in sql_lex.cc.
During the code cleanup in case MY_LEX_NUMBER_IDENT,
Bug 28127 (Some valid identifiers names are not parsed correctly)
was found and fixed.
By parsing special comments properly, and removing the function
'skip_rear_comments' [sic],
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
has been fixed as well.
sql/event_data_objects.cc:
Cleanup of the code that extracts the query text
sql/sp.cc:
Cleanup of the code that extracts the query text
sql/sp_head.cc:
Cleanup of the code that extracts the query text
sql/sql_trigger.cc:
Cleanup of the code that extracts the query text
sql/sql_view.cc:
Cleanup of the code that extracts the query text
mysql-test/r/comments.result:
Bug#25411 (trigger code truncated)
mysql-test/r/sp.result:
Bug#25411 (trigger code truncated)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
mysql-test/r/trigger.result:
Bug#25411 (trigger code truncated)
mysql-test/r/varbinary.result:
Bug 28127 (Some valid identifiers names are not parsed correctly)
mysql-test/t/comments.test:
Bug#25411 (trigger code truncated)
mysql-test/t/sp.test:
Bug#25411 (trigger code truncated)
Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
mysql-test/t/trigger.test:
Bug#25411 (trigger code truncated)
mysql-test/t/varbinary.test:
Bug 28127 (Some valid identifiers names are not parsed correctly)
sql/sql_lex.cc:
Implemented comment pre-processing in Lex_input_stream,
major cleanup of the lex/yacc code to not use Lex_input_stream private members.
sql/sql_lex.h:
Implemented comment pre-processing in Lex_input_stream,
major cleanup of the lex/yacc code to not use Lex_input_stream private members.
sql/sql_yacc.yy:
post merge fix : view_check_options must be parsed before signaling the end of the query
2007-06-12 23:23:58 +02:00
|
|
|
|
|
|
|
#
|
|
|
|
# Bug#28127 (Some valid identifiers names are not parsed correctly)
|
|
|
|
#
|
|
|
|
|
|
|
|
--disable_warnings
|
|
|
|
drop table if exists table_28127_a;
|
|
|
|
drop table if exists table_28127_b;
|
|
|
|
--enable_warnings
|
|
|
|
|
|
|
|
create table table_28127_a(0b02 int);
|
|
|
|
show create table table_28127_a;
|
|
|
|
|
|
|
|
create table table_28127_b(0b2 int);
|
|
|
|
show create table table_28127_b;
|
|
|
|
|
|
|
|
drop table table_28127_a;
|
|
|
|
drop table table_28127_b;
|
|
|
|
|
2008-06-27 15:22:23 +02:00
|
|
|
#
|
|
|
|
# Bug#35658 (An empty binary value leads to mysqld crash)
|
|
|
|
#
|
|
|
|
|
|
|
|
select 0b01000001;
|
|
|
|
|
|
|
|
select 0x41;
|
|
|
|
|
|
|
|
select b'01000001';
|
|
|
|
|
The bug
MDEV-4489 "Replication of big5, cp932, gbk, sjis strings makes wrong values on slave"
has been fixed.
Problem:
String constants of some Asian charsets (big5,cp932,gbk,sjis)
can have backslash '\' (0x5C) in the second byte of multi-byte characters.
Replicating of such constants using the standard '\'-escaping is dangerous.
Therefore, constants of these charsets are replicated using hex notation:
INSERT INTO t1 (a) VALUES (0x815C);
However, 0xHHHH constants do not work well in some cases,
because they can behave as strings and as numbers, depending on context
(for example, depending on the data type of the column in an INSERT statement).
This SQL script was not replicated correctly with statement-based replication:
SET NAMES gbk;
PREPARE STMT FROM 'INSERT INTO t1 (a) VALUES (?)';
SET @a = '1';
EXECUTE STMT USING @a;
The INSERT statement was replicated as:
INSERT INTO t1 (a) VALUES (0x31);
'1' was correctly converted to the number 1 on master.
But the 0x31 constant was treated as number 49 on slave.
Fix:
1. Binary log now uses X'HHHH' instead of 0xHHHH constants.
2. The X'HHHH' constants now work always as strings, in all contexts.
This is the SQL standard compliant behaviour.
After the fix, the above statement is replicated as:
INSERT INTO t1 (a) VALUES (X'31');
X'31' is treated as string '1' on slave, and is correctly converted to 1.
modified:
@ mysql-test/r/ctype_cp932_binlog_stm.result
@ mysql-test/r/select.result
@ mysql-test/r/select_jcl6.result
@ mysql-test/r/select_pkeycache.result
@ mysql-test/r/user_var-binlog.result
@ mysql-test/r/varbinary.result
@ mysql-test/suite/binlog/r/binlog_stm_ctype_ucs.result
@ mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result
@ mysql-test/suite/rpl/r/rpl_charset_sjis.result
@ mysql-test/suite/rpl/r/rpl_mdev382.result
@ mysql-test/suite/rpl/t/rpl_charset_sjis.test
@ mysql-test/t/ctype_cp932_binlog_stm.test
@ mysql-test/t/select.test
@ mysql-test/t/varbinary.test
Adding and updating tests
@ sql/item.cc
@ sql/item.h
@ sql/sql_yacc.yy
@ sql/sql_lex.cc
Splitting the implementations of X'HH' and 0xHH constants into two
separate classes. Fixing the parser to distinguish the two syntaxes.
@ sql/log_event.cc
Using X'HH' instead of 0xHH for binary logging for string constants
of the "dangerous" charsets.
@ sql/sql_string.h
Adding a helped method String::append_hex().
2013-05-08 11:36:17 +02:00
|
|
|
select x'41', 0+x'3635';
|
2008-06-27 15:22:23 +02:00
|
|
|
|
|
|
|
select N'abc', length(N'abc');
|
|
|
|
|
2022-06-09 05:32:51 +02:00
|
|
|
#enable after fix MDEV-28535
|
|
|
|
--disable_view_protocol
|
2008-06-27 15:22:23 +02:00
|
|
|
select N'', length(N'');
|
|
|
|
|
|
|
|
select '', length('');
|
2022-06-09 05:32:51 +02:00
|
|
|
--enable_view_protocol
|
2008-06-27 15:22:23 +02:00
|
|
|
|
|
|
|
select b'', 0+b'';
|
|
|
|
|
|
|
|
select x'', 0+x'';
|
|
|
|
|
|
|
|
--error ER_BAD_FIELD_ERROR
|
|
|
|
select 0x;
|
|
|
|
|
|
|
|
--error ER_BAD_FIELD_ERROR
|
|
|
|
select 0b;
|
|
|
|
|