Bug#20691: DATETIME col (NOT NULL, NO DEFAULT) may insert garbage when \

	specifying DEFAULT

This was not specific to datetime.  When there is no default value 
for a column, and the user inserted DEFAULT, we would write 
uninitialized memory to the table.  

Now, insist on writing a default value, a zero-ish value, the same 
one that comes from inserting NULL into a not-NULL field.

(This is, at best, really strange behavior that comes from allowing 
sloppy usage, and serves as a good reason always to run one's server 
in a strict SQL mode.)


mysql-test/r/default.result:
  Verify that all kinds of types work, even others other than datetime.
mysql-test/t/default.test:
  Verify that all kinds of types work, even others other than datetime.
sql/item.cc:
  Even if we warn that there is no default value in the table definition,
  we have to insert /something/.

1 files changed, 58 insertions, 0 deletions

diff --git a/mysql-test/t/default.test b/mysql-test/t/default.test
index b5522394d2d..225ddbc3ee2 100644
--- a/mysql-test/t/default.test
+++ b/mysql-test/t/default.test
@@ -82,3 +82,61 @@ SELECT * from t2;
 drop table t1;
 drop table t2;
 
+
+#
+# Bug#20691: DATETIME col (NOT NULL, NO DEFAULT) may insert garbage when specifying DEFAULT
+#
+# From the docs:
+#  If the column can take NULL as a value, the column is defined with an
+#  explicit DEFAULT NULL clause. This is the same as before 5.0.2.
+#
+#  If the column cannot take NULL as the value, MySQL defines the column with
+#  no explicit DEFAULT clause. For data entry, if an INSERT or REPLACE
+#  statement includes no value for the column, MySQL handles the column
+#  according to the SQL mode in effect at the time:
+#
+#    * If strict SQL mode is not enabled, MySQL sets the column to the
+#      implicit default value for the column data type.
+#
+#    * If strict mode is enabled, an error occurs for transactional tables and
+#      the statement is rolled back. For non-transactional tables, an error
+#      occurs, but if this happens for the second or subsequent row of a
+#      multiple-row statement, the preceding rows will have been inserted.
+#
+create table bug20691 (i int, d datetime NOT NULL, dn datetime not null default '0000-00-00 00:00:00');
+insert into bug20691 values (1, DEFAULT, DEFAULT), (1, '1975-07-10 07:10:03', '1978-01-13 14:08:51'), (1, DEFAULT, DEFAULT);
+insert into bug20691 (i) values (2);
+desc bug20691;
+insert into bug20691 values (3, DEFAULT, DEFAULT), (3, '1975-07-10 07:10:03', '1978-01-13 14:08:51'), (3, DEFAULT, DEFAULT);
+insert into bug20691 (i) values (4);
+insert into bug20691 values (5, DEFAULT, DEFAULT), (5, '1975-07-10 07:10:03', '1978-01-13 14:08:51'), (5, DEFAULT, DEFAULT);
+SET sql_mode = 'ALLOW_INVALID_DATES';
+insert into bug20691 values (6, DEFAULT, DEFAULT), (6, '1975-07-10 07:10:03', '1978-01-13 14:08:51'), (6, DEFAULT, DEFAULT);
+SET sql_mode = 'STRICT_ALL_TABLES';
+--error 1364
+insert into bug20691 values (7, DEFAULT, DEFAULT), (7, '1975-07-10 07:10:03', '1978-01-13 14:08:51'), (7, DEFAULT, DEFAULT);
+select * from bug20691 order by i asc;
+drop table bug20691;
+
+SET sql_mode = '';
+create table bug20691 (
+  a set('one', 'two', 'three') not null,
+  b enum('small', 'medium', 'large', 'enormous', 'ellisonego') not null,
+  c time not null,
+  d date not null,
+  e int not null,
+  f long not null,
+  g blob not null,
+  h datetime not null,
+  i decimal not null,
+  x int);
+insert into bug20691 values (2, 3, 5, '0007-01-01', 11, 13, 17, '0019-01-01 00:00:00', 23, 1);
+insert into bug20691 (x) values (2);
+insert into bug20691 values (2, 3, 5, '0007-01-01', 11, 13, 17, '0019-01-01 00:00:00', 23, 3);
+insert into bug20691 values (DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, 4);
+select * from bug20691 order by x asc;
+drop table bug20691;
+
+###
+--echo End of 5.0 tests.
+