2006-10-24 17:54:45 +02:00
|
|
|
drop table if exists t1, t2, t3, t4, t5, t6;
|
2005-09-27 07:43:09 +02:00
|
|
|
create table t1 (id int(8), name varchar(32));
|
|
|
|
|
create table t2 (id int(8), name varchar(32)) ENGINE="MyISAM";
|
|
|
|
|
create table t3 (id int(8), name varchar(32)) ENGINE="MEMORY";
|
|
|
|
|
create table t4 (id int(8), name varchar(32)) ENGINE="HEAP";
|
|
|
|
|
create table t5 (id int(8), name varchar(32)) ENGINE="ARCHIVE";
|
|
|
|
|
create table t6 (id int(8), name varchar(32)) ENGINE="InnoDB";
|
|
|
|
|
insert into t1 values (1, 'first value');
|
|
|
|
|
insert into t1 values (2, 'first value');
|
|
|
|
|
insert into t1 values (3, 'first value');
|
|
|
|
|
insert into t1 values (4, 'first value');
|
|
|
|
|
insert into t1 values (5, 'first value');
|
|
|
|
|
insert into t2 values (1, 'first value');
|
|
|
|
|
insert into t2 values (2, 'first value');
|
|
|
|
|
insert into t2 values (3, 'first value');
|
|
|
|
|
insert into t2 values (4, 'first value');
|
|
|
|
|
insert into t2 values (5, 'first value');
|
|
|
|
|
insert into t3 values (1, 'first value');
|
|
|
|
|
insert into t3 values (2, 'first value');
|
|
|
|
|
insert into t3 values (3, 'first value');
|
|
|
|
|
insert into t3 values (4, 'first value');
|
|
|
|
|
insert into t3 values (5, 'first value');
|
|
|
|
|
insert into t4 values (1, 'first value');
|
|
|
|
|
insert into t4 values (2, 'first value');
|
|
|
|
|
insert into t4 values (3, 'first value');
|
|
|
|
|
insert into t4 values (4, 'first value');
|
|
|
|
|
insert into t4 values (5, 'first value');
|
|
|
|
|
insert into t5 values (1, 'first value');
|
|
|
|
|
insert into t5 values (2, 'first value');
|
|
|
|
|
insert into t5 values (3, 'first value');
|
|
|
|
|
insert into t5 values (4, 'first value');
|
|
|
|
|
insert into t5 values (5, 'first value');
|
|
|
|
|
insert into t6 values (1, 'first value');
|
|
|
|
|
insert into t6 values (2, 'first value');
|
|
|
|
|
insert into t6 values (3, 'first value');
|
|
|
|
|
insert into t6 values (4, 'first value');
|
|
|
|
|
insert into t6 values (5, 'first value');
|
|
|
|
|
select * from t1;
|
|
|
|
|
id name
|
|
|
|
|
1 first value
|
|
|
|
|
2 first value
|
|
|
|
|
3 first value
|
|
|
|
|
4 first value
|
|
|
|
|
5 first value
|
|
|
|
|
select * from t2;
|
|
|
|
|
id name
|
|
|
|
|
1 first value
|
|
|
|
|
2 first value
|
|
|
|
|
3 first value
|
|
|
|
|
4 first value
|
|
|
|
|
5 first value
|
|
|
|
|
select * from t3;
|
|
|
|
|
id name
|
|
|
|
|
1 first value
|
|
|
|
|
2 first value
|
|
|
|
|
3 first value
|
|
|
|
|
4 first value
|
|
|
|
|
5 first value
|
|
|
|
|
select * from t4;
|
|
|
|
|
id name
|
|
|
|
|
1 first value
|
|
|
|
|
2 first value
|
|
|
|
|
3 first value
|
|
|
|
|
4 first value
|
|
|
|
|
5 first value
|
|
|
|
|
select * from t5;
|
|
|
|
|
id name
|
|
|
|
|
1 first value
|
|
|
|
|
2 first value
|
|
|
|
|
3 first value
|
|
|
|
|
4 first value
|
|
|
|
|
5 first value
|
|
|
|
|
select * from t6;
|
|
|
|
|
id name
|
|
|
|
|
1 first value
|
|
|
|
|
2 first value
|
|
|
|
|
3 first value
|
|
|
|
|
4 first value
|
|
|
|
|
5 first value
|
|
|
|
|
|
|
|
|
|
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
|
|
|
|
|
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
|
|
|
|
|
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
|
|
|
|
|
/*!40101 SET NAMES utf8 */;
|
2005-10-13 18:28:44 +02:00
|
|
|
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
|
|
|
|
|
/*!40103 SET TIME_ZONE='+00:00' */;
|
2005-09-27 07:43:09 +02:00
|
|
|
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
|
|
|
|
|
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
|
|
|
|
|
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
|
|
|
|
|
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
|
|
|
|
|
|
|
|
|
|
CREATE DATABASE /*!32312 IF NOT EXISTS*/ `test` /*!40100 DEFAULT CHARACTER SET latin1 */;
|
|
|
|
|
|
|
|
|
|
USE `test`;
|
|
|
|
|
DROP TABLE IF EXISTS `t1`;
|
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
|
|
|
/*!40101 SET @saved_cs_client = @@character_set_client */;
|
|
|
|
|
/*!40101 SET character_set_client = utf8 */;
|
2005-09-27 07:43:09 +02:00
|
|
|
CREATE TABLE `t1` (
|
2006-02-22 10:09:59 +01:00
|
|
|
`id` int(8) DEFAULT NULL,
|
|
|
|
|
`name` varchar(32) DEFAULT NULL
|
2005-09-27 07:43:09 +02:00
|
|
|
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
|
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
|
|
|
/*!40101 SET character_set_client = @saved_cs_client */;
|
2005-09-27 07:43:09 +02:00
|
|
|
|
|
|
|
|
/*!40000 ALTER TABLE `t1` DISABLE KEYS */;
|
|
|
|
|
INSERT DELAYED IGNORE INTO `t1` VALUES (1,'first value'),(2,'first value'),(3,'first value'),(4,'first value'),(5,'first value');
|
|
|
|
|
/*!40000 ALTER TABLE `t1` ENABLE KEYS */;
|
|
|
|
|
DROP TABLE IF EXISTS `t2`;
|
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
|
|
|
/*!40101 SET @saved_cs_client = @@character_set_client */;
|
|
|
|
|
/*!40101 SET character_set_client = utf8 */;
|
2005-09-27 07:43:09 +02:00
|
|
|
CREATE TABLE `t2` (
|
2006-02-22 10:09:59 +01:00
|
|
|
`id` int(8) DEFAULT NULL,
|
|
|
|
|
`name` varchar(32) DEFAULT NULL
|
2005-09-27 07:43:09 +02:00
|
|
|
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
|
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
|
|
|
/*!40101 SET character_set_client = @saved_cs_client */;
|
2005-09-27 07:43:09 +02:00
|
|
|
|
|
|
|
|
/*!40000 ALTER TABLE `t2` DISABLE KEYS */;
|
|
|
|
|
INSERT DELAYED IGNORE INTO `t2` VALUES (1,'first value'),(2,'first value'),(3,'first value'),(4,'first value'),(5,'first value');
|
|
|
|
|
/*!40000 ALTER TABLE `t2` ENABLE KEYS */;
|
|
|
|
|
DROP TABLE IF EXISTS `t3`;
|
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
|
|
|
/*!40101 SET @saved_cs_client = @@character_set_client */;
|
|
|
|
|
/*!40101 SET character_set_client = utf8 */;
|
2005-09-27 07:43:09 +02:00
|
|
|
CREATE TABLE `t3` (
|
2006-02-22 10:09:59 +01:00
|
|
|
`id` int(8) DEFAULT NULL,
|
|
|
|
|
`name` varchar(32) DEFAULT NULL
|
2005-09-27 07:43:09 +02:00
|
|
|
) ENGINE=MEMORY DEFAULT CHARSET=latin1;
|
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
|
|
|
/*!40101 SET character_set_client = @saved_cs_client */;
|
2005-09-27 07:43:09 +02:00
|
|
|
|
|
|
|
|
/*!40000 ALTER TABLE `t3` DISABLE KEYS */;
|
|
|
|
|
INSERT DELAYED IGNORE INTO `t3` VALUES (1,'first value'),(2,'first value'),(3,'first value'),(4,'first value'),(5,'first value');
|
|
|
|
|
/*!40000 ALTER TABLE `t3` ENABLE KEYS */;
|
|
|
|
|
DROP TABLE IF EXISTS `t4`;
|
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
|
|
|
/*!40101 SET @saved_cs_client = @@character_set_client */;
|
|
|
|
|
/*!40101 SET character_set_client = utf8 */;
|
2005-09-27 07:43:09 +02:00
|
|
|
CREATE TABLE `t4` (
|
2006-02-22 10:09:59 +01:00
|
|
|
`id` int(8) DEFAULT NULL,
|
|
|
|
|
`name` varchar(32) DEFAULT NULL
|
2005-09-27 07:43:09 +02:00
|
|
|
) ENGINE=MEMORY DEFAULT CHARSET=latin1;
|
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
|
|
|
/*!40101 SET character_set_client = @saved_cs_client */;
|
2005-09-27 07:43:09 +02:00
|
|
|
|
|
|
|
|
/*!40000 ALTER TABLE `t4` DISABLE KEYS */;
|
|
|
|
|
INSERT DELAYED IGNORE INTO `t4` VALUES (1,'first value'),(2,'first value'),(3,'first value'),(4,'first value'),(5,'first value');
|
|
|
|
|
/*!40000 ALTER TABLE `t4` ENABLE KEYS */;
|
|
|
|
|
DROP TABLE IF EXISTS `t5`;
|
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
|
|
|
/*!40101 SET @saved_cs_client = @@character_set_client */;
|
|
|
|
|
/*!40101 SET character_set_client = utf8 */;
|
2005-09-27 07:43:09 +02:00
|
|
|
CREATE TABLE `t5` (
|
2006-02-22 10:09:59 +01:00
|
|
|
`id` int(8) DEFAULT NULL,
|
|
|
|
|
`name` varchar(32) DEFAULT NULL
|
2005-09-27 07:43:09 +02:00
|
|
|
) ENGINE=ARCHIVE DEFAULT CHARSET=latin1;
|
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
|
|
|
/*!40101 SET character_set_client = @saved_cs_client */;
|
2005-09-27 07:43:09 +02:00
|
|
|
|
|
|
|
|
/*!40000 ALTER TABLE `t5` DISABLE KEYS */;
|
|
|
|
|
INSERT DELAYED IGNORE INTO `t5` VALUES (1,'first value'),(2,'first value'),(3,'first value'),(4,'first value'),(5,'first value');
|
|
|
|
|
/*!40000 ALTER TABLE `t5` ENABLE KEYS */;
|
|
|
|
|
DROP TABLE IF EXISTS `t6`;
|
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
|
|
|
/*!40101 SET @saved_cs_client = @@character_set_client */;
|
|
|
|
|
/*!40101 SET character_set_client = utf8 */;
|
2005-09-27 07:43:09 +02:00
|
|
|
CREATE TABLE `t6` (
|
2006-02-22 10:09:59 +01:00
|
|
|
`id` int(8) DEFAULT NULL,
|
|
|
|
|
`name` varchar(32) DEFAULT NULL
|
2005-09-27 07:43:09 +02:00
|
|
|
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
|
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
|
|
|
/*!40101 SET character_set_client = @saved_cs_client */;
|
2005-09-27 07:43:09 +02:00
|
|
|
|
|
|
|
|
/*!40000 ALTER TABLE `t6` DISABLE KEYS */;
|
|
|
|
|
INSERT IGNORE INTO `t6` VALUES (1,'first value'),(2,'first value'),(3,'first value'),(4,'first value'),(5,'first value');
|
|
|
|
|
/*!40000 ALTER TABLE `t6` ENABLE KEYS */;
|
2005-10-13 18:28:44 +02:00
|
|
|
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;
|
2005-09-27 07:43:09 +02:00
|
|
|
|
|
|
|
|
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
|
|
|
|
|
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
|
|
|
|
|
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
|
|
|
|
|
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
|
|
|
|
|
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
|
|
|
|
|
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
|
|
|
|
|
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
|
|
|
|
|
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
|
|
|
|
|
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
|
|
|
|
|
/*!40101 SET NAMES utf8 */;
|
2005-10-13 18:28:44 +02:00
|
|
|
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
|
|
|
|
|
/*!40103 SET TIME_ZONE='+00:00' */;
|
2005-09-27 07:43:09 +02:00
|
|
|
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
|
|
|
|
|
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
|
|
|
|
|
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
|
|
|
|
|
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
|
|
|
|
|
|
|
|
|
|
CREATE DATABASE /*!32312 IF NOT EXISTS*/ `test` /*!40100 DEFAULT CHARACTER SET latin1 */;
|
|
|
|
|
|
|
|
|
|
USE `test`;
|
|
|
|
|
DROP TABLE IF EXISTS `t1`;
|
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
|
|
|
/*!40101 SET @saved_cs_client = @@character_set_client */;
|
|
|
|
|
/*!40101 SET character_set_client = utf8 */;
|
2005-09-27 07:43:09 +02:00
|
|
|
CREATE TABLE `t1` (
|
2006-02-22 10:09:59 +01:00
|
|
|
`id` int(8) DEFAULT NULL,
|
|
|
|
|
`name` varchar(32) DEFAULT NULL
|
2005-09-27 07:43:09 +02:00
|
|
|
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
|
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
|
|
|
/*!40101 SET character_set_client = @saved_cs_client */;
|
2005-09-27 07:43:09 +02:00
|
|
|
|
|
|
|
|
/*!40000 ALTER TABLE `t1` DISABLE KEYS */;
|
|
|
|
|
INSERT DELAYED INTO `t1` VALUES (1,'first value'),(2,'first value'),(3,'first value'),(4,'first value'),(5,'first value');
|
|
|
|
|
/*!40000 ALTER TABLE `t1` ENABLE KEYS */;
|
|
|
|
|
DROP TABLE IF EXISTS `t2`;
|
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
|
|
|
/*!40101 SET @saved_cs_client = @@character_set_client */;
|
|
|
|
|
/*!40101 SET character_set_client = utf8 */;
|
2005-09-27 07:43:09 +02:00
|
|
|
CREATE TABLE `t2` (
|
2006-02-22 10:09:59 +01:00
|
|
|
`id` int(8) DEFAULT NULL,
|
|
|
|
|
`name` varchar(32) DEFAULT NULL
|
2005-09-27 07:43:09 +02:00
|
|
|
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
|
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
|
|
|
/*!40101 SET character_set_client = @saved_cs_client */;
|
2005-09-27 07:43:09 +02:00
|
|
|
|
|
|
|
|
/*!40000 ALTER TABLE `t2` DISABLE KEYS */;
|
|
|
|
|
INSERT DELAYED INTO `t2` VALUES (1,'first value'),(2,'first value'),(3,'first value'),(4,'first value'),(5,'first value');
|
|
|
|
|
/*!40000 ALTER TABLE `t2` ENABLE KEYS */;
|
|
|
|
|
DROP TABLE IF EXISTS `t3`;
|
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
|
|
|
/*!40101 SET @saved_cs_client = @@character_set_client */;
|
|
|
|
|
/*!40101 SET character_set_client = utf8 */;
|
2005-09-27 07:43:09 +02:00
|
|
|
CREATE TABLE `t3` (
|
2006-02-22 10:09:59 +01:00
|
|
|
`id` int(8) DEFAULT NULL,
|
|
|
|
|
`name` varchar(32) DEFAULT NULL
|
2005-09-27 07:43:09 +02:00
|
|
|
) ENGINE=MEMORY DEFAULT CHARSET=latin1;
|
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
|
|
|
/*!40101 SET character_set_client = @saved_cs_client */;
|
2005-09-27 07:43:09 +02:00
|
|
|
|
|
|
|
|
/*!40000 ALTER TABLE `t3` DISABLE KEYS */;
|
|
|
|
|
INSERT DELAYED INTO `t3` VALUES (1,'first value'),(2,'first value'),(3,'first value'),(4,'first value'),(5,'first value');
|
|
|
|
|
/*!40000 ALTER TABLE `t3` ENABLE KEYS */;
|
|
|
|
|
DROP TABLE IF EXISTS `t4`;
|
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
|
|
|
/*!40101 SET @saved_cs_client = @@character_set_client */;
|
|
|
|
|
/*!40101 SET character_set_client = utf8 */;
|
2005-09-27 07:43:09 +02:00
|
|
|
CREATE TABLE `t4` (
|
2006-02-22 10:09:59 +01:00
|
|
|
`id` int(8) DEFAULT NULL,
|
|
|
|
|
`name` varchar(32) DEFAULT NULL
|
2005-09-27 07:43:09 +02:00
|
|
|
) ENGINE=MEMORY DEFAULT CHARSET=latin1;
|
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
|
|
|
/*!40101 SET character_set_client = @saved_cs_client */;
|
2005-09-27 07:43:09 +02:00
|
|
|
|
|
|
|
|
/*!40000 ALTER TABLE `t4` DISABLE KEYS */;
|
|
|
|
|
INSERT DELAYED INTO `t4` VALUES (1,'first value'),(2,'first value'),(3,'first value'),(4,'first value'),(5,'first value');
|
|
|
|
|
/*!40000 ALTER TABLE `t4` ENABLE KEYS */;
|
|
|
|
|
DROP TABLE IF EXISTS `t5`;
|
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
|
|
|
/*!40101 SET @saved_cs_client = @@character_set_client */;
|
|
|
|
|
/*!40101 SET character_set_client = utf8 */;
|
2005-09-27 07:43:09 +02:00
|
|
|
CREATE TABLE `t5` (
|
2006-02-22 10:09:59 +01:00
|
|
|
`id` int(8) DEFAULT NULL,
|
|
|
|
|
`name` varchar(32) DEFAULT NULL
|
2005-09-27 07:43:09 +02:00
|
|
|
) ENGINE=ARCHIVE DEFAULT CHARSET=latin1;
|
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
|
|
|
/*!40101 SET character_set_client = @saved_cs_client */;
|
2005-09-27 07:43:09 +02:00
|
|
|
|
|
|
|
|
/*!40000 ALTER TABLE `t5` DISABLE KEYS */;
|
|
|
|
|
INSERT DELAYED INTO `t5` VALUES (1,'first value'),(2,'first value'),(3,'first value'),(4,'first value'),(5,'first value');
|
|
|
|
|
/*!40000 ALTER TABLE `t5` ENABLE KEYS */;
|
|
|
|
|
DROP TABLE IF EXISTS `t6`;
|
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
|
|
|
/*!40101 SET @saved_cs_client = @@character_set_client */;
|
|
|
|
|
/*!40101 SET character_set_client = utf8 */;
|
2005-09-27 07:43:09 +02:00
|
|
|
CREATE TABLE `t6` (
|
2006-02-22 10:09:59 +01:00
|
|
|
`id` int(8) DEFAULT NULL,
|
|
|
|
|
`name` varchar(32) DEFAULT NULL
|
2005-09-27 07:43:09 +02:00
|
|
|
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
|
Bug#33550: mysqldump 4.0 compatibility broken
mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
client/mysqldump.c:
in 3.23/4.0 compat mode, don't do charset magic,
period. not in output, but not on the server,
either!
mysql-test/r/mysqldump-max.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/mysqldump.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/r/openssl_1.result:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
mysql-test/t/mysqldump.test:
character_set_client magic lives in version-conditional
now (except in compat 3.23/4.0 mode, in which case we
don't output any at all!).
2009-02-02 18:19:07 +01:00
|
|
|
/*!40101 SET character_set_client = @saved_cs_client */;
|
2005-09-27 07:43:09 +02:00
|
|
|
|
|
|
|
|
/*!40000 ALTER TABLE `t6` DISABLE KEYS */;
|
|
|
|
|
INSERT INTO `t6` VALUES (1,'first value'),(2,'first value'),(3,'first value'),(4,'first value'),(5,'first value');
|
|
|
|
|
/*!40000 ALTER TABLE `t6` ENABLE KEYS */;
|
2005-10-13 18:28:44 +02:00
|
|
|
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;
|
2005-09-27 07:43:09 +02:00
|
|
|
|
|
|
|
|
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
|
|
|
|
|
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
|
|
|
|
|
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
|
|
|
|
|
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
|
|
|
|
|
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
|
|
|
|
|
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
|
|
|
|
|
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;
|
|
|
|
|
|
|
|
|
|
drop table t1;
|
|
|
|
|
drop table t2;
|
|
|
|
|
drop table t3;
|
|
|
|
|
drop table t4;
|
|
|
|
|
drop table t5;
|
|
|
|
|
drop table t6;
|
2008-09-11 08:14:19 +02:00
|
|
|
SELECT @@global.storage_engine INTO @old_engine;
|
|
|
|
|
SET GLOBAL storage_engine=InnoDB;
|
|
|
|
|
CREATE VIEW v1 AS SELECT * FROM t1;
|
|
|
|
|
INSERT INTO t1 VALUES();
|
|
|
|
|
SELECT COUNT(*) FROM v1;
|
|
|
|
|
COUNT(*)
|
|
|
|
|
1
|
|
|
|
|
SELECT COUNT(*) FROM v1;
|
|
|
|
|
COUNT(*)
|
|
|
|
|
1
|
|
|
|
|
DROP VIEW v1;
|
|
|
|
|
DROP TABLE t1;
|
|
|
|
|
SET GLOBAL storage_engine=@old_engine;
|
2016-03-25 17:51:22 +01:00
|
|
|
connect c1,127.0.0.1,root,,test,$MASTER_MYPORT,;
|
|
|
|
|
connect c2,127.0.0.1,root,,test,$MASTER_MYPORT,;
|
|
|
|
|
connect c3,127.0.0.1,root,,test,$MASTER_MYPORT,;
|
|
|
|
|
connection default;
|
2010-11-08 09:11:44 +01:00
|
|
|
SET binlog_format= mixed;
|
2010-11-07 22:37:43 +01:00
|
|
|
RESET MASTER;
|
|
|
|
|
CREATE TABLE t1 (a INT PRIMARY KEY) ENGINE=InnoDB;
|
|
|
|
|
INSERT INTO t1 VALUES (1),(2);
|
|
|
|
|
CREATE TABLE t2 (a INT PRIMARY KEY, b INT) ENGINE=InnoDB;
|
|
|
|
|
INSERT INTO t2 VALUES (1,0), (2,0);
|
|
|
|
|
SELECT GET_LOCK("block_queries_1", 120);
|
|
|
|
|
GET_LOCK("block_queries_1", 120)
|
|
|
|
|
1
|
2016-03-25 17:51:22 +01:00
|
|
|
connection c3;
|
2010-11-07 22:37:43 +01:00
|
|
|
SELECT GET_LOCK("block_queries_2", 120);
|
|
|
|
|
GET_LOCK("block_queries_2", 120)
|
|
|
|
|
1
|
2016-03-25 17:51:22 +01:00
|
|
|
connection c1;
|
2010-11-07 22:37:43 +01:00
|
|
|
SET @c= 0;
|
|
|
|
|
SELECT IF(@c<1, @c:=@c+1, GET_LOCK("block_queries_1", 120)) FROM t1 ORDER BY a;
|
2016-03-25 17:51:22 +01:00
|
|
|
connection c2;
|
2010-11-07 22:37:43 +01:00
|
|
|
SET binlog_format="row";
|
|
|
|
|
SET @d= 10;
|
|
|
|
|
UPDATE t2 SET b=IF(@d<=10, @d:=@d+1, GET_LOCK("block_queries_2", 120)) ORDER BY a;
|
2016-03-25 17:51:22 +01:00
|
|
|
connection default;
|
2010-11-07 22:37:43 +01:00
|
|
|
# Make sure other queries are running (and waiting).
|
|
|
|
|
SELECT RELEASE_LOCK("block_queries_1");
|
|
|
|
|
RELEASE_LOCK("block_queries_1")
|
|
|
|
|
1
|
2016-03-25 17:51:22 +01:00
|
|
|
connection c3;
|
2010-11-07 22:37:43 +01:00
|
|
|
SELECT RELEASE_LOCK("block_queries_2");
|
|
|
|
|
RELEASE_LOCK("block_queries_2")
|
|
|
|
|
1
|
2016-03-25 17:51:22 +01:00
|
|
|
connection c1;
|
2010-11-07 22:37:43 +01:00
|
|
|
IF(@c<1, @c:=@c+1, GET_LOCK("block_queries_1", 120))
|
|
|
|
|
1
|
|
|
|
|
1
|
2016-03-25 17:51:22 +01:00
|
|
|
connection c2;
|
|
|
|
|
connection default;
|
2010-11-07 22:37:43 +01:00
|
|
|
SELECT * FROM t2 ORDER BY a;
|
|
|
|
|
a b
|
|
|
|
|
1 11
|
|
|
|
|
2 1
|
|
|
|
|
DROP TABLE t1;
|
|
|
|
|
DROP TABLE t2;
|
2015-08-21 23:20:35 +02:00
|
|
|
include/show_binlog_events.inc
|
2010-11-07 22:37:43 +01:00
|
|
|
Log_name Pos Event_type Server_id End_log_pos Info
|
2015-08-21 23:20:35 +02:00
|
|
|
master-bin.000001 # Gtid # # BEGIN GTID #-#-#
|
|
|
|
|
master-bin.000001 # Query # # use `test`; INSERT INTO t2 VALUES (1,0), (2,0)
|
|
|
|
|
master-bin.000001 # Xid # # COMMIT /* XID */
|
|
|
|
|
-- CHANGE MASTER TO MASTER_LOG_FILE='master-bin.000001', MASTER_LOG_POS=<pos>;
|
2010-11-07 22:37:43 +01:00
|
|
|
SELECT * FROM t1 ORDER BY a;
|
|
|
|
|
a
|
|
|
|
|
1
|
|
|
|
|
2
|
|
|
|
|
SELECT * FROM t2 ORDER BY a;
|
|
|
|
|
a b
|
|
|
|
|
1 0
|
|
|
|
|
2 0
|
|
|
|
|
DROP TABLE t1,t2;
|