MDEV-10780 Server crashes in in create_tmp_table
MDEV-11265 Access defied when CREATE VIIEW v1 AS SELECT DEFAULT(column) FROM t1
Item_default_value and Item_insert_value erroneously derive from Item_field
but forgot to override some methods that apply only to true fields,
so the server code mixes Item_{default|insert}_value instances with real
table fields (i.e. true Item_field) in some cases.
Overriding a few methods to avoid this.
TODO: we should eventually derive Item_default_value (and Item_insert_value)
directly from Item, as they don't really need the entire Item_field,
Item_ident and Item_result_field functionality.
Only the member "Field *field" related functionality is actually needed,
like val_xxx(), is_null(), get_geometry_type(), charset_for_protocol(), etc.
INSERT .. SELECT .. ON DUPLICATE KEY UPDATE col=DEFAULT
In order to get correct values from update fields that
belongs to the SELECT part in the INSERT .. SELECT .. ON
DUPLICATE KEY UPDATE statement, the server adds referenced
fields to the select list. Part of the code that does this
transformation is shared between implementations of
the DEFAULT(col) function and the DEFAULT keyword (in
the col=DEFAULT expression), and an implementation of
the DEFAULT keyword is incomplete.
mysql-test/r/default.result:
Added test case for bug #39002.
mysql-test/t/default.test:
Added test case for bug #39002.
sql/item.cc:
The Item_default_value::transform() function has been
modified to take into account the fact that the DEFAULT
keyword has no arguments unlike the DEFAULT(col) function
that always has an argument.
Some fields (GEOMETRY first of all) can't be handled properly in this
case at all. So we return an error in this case
mysql-test/r/default.result:
result fixed
mysql-test/r/gis.result:
result fixed
mysql-test/t/default.test:
VIEW test added
mysql-test/t/gis.test:
testcase added
sql/item.cc:
set_defaults() changed with the 'reset()'
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/.
Moved enabling of warnings to ensure that no warnings are generated
when this test case is executed on a clone where InnoDB is not
activated. This would fail the test case in those clones otherwise.
mysql-test/r/default.result:
Rename: mysql-test/r/bugs.result -> mysql-test/r/default.result
mysql-test/t/default.test:
Moved enabling of warnings to ensure that no warnings are generated
when this test case is executed on a clone where InnoDB is not
activated. This would fail the test case in those clones otherwise.
