1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-24 19:42:23 +03:00
Commit Graph

6 Commits

Author SHA1 Message Date
f1544424de MDEV-29446 Change SHOW CREATE TABLE to display default collation 2022-09-12 22:10:39 +04:00
c4ab352b67 MDEV-14576 Include full name of object in message about incorrect value for column.
The error message modified.
Then the TABLE_SHARE::error_table_name() implementation taken from 10.3,
          to be used as a name of the table in this message.
2018-12-16 02:21:41 +04:00
8b2e642aa2 MDEV-7635: Update tests to adapt to the new default sql_mode 2017-02-10 06:30:42 -05:00
6c173324ff Part of MDEV-10134 Add full support for DEFAULT
Print default values for BLOB's.
This is a part commit for automatic changes to make the real commit smaller.
All changes here are related to that we now print DEFAULT NULL for blob and
text fields, like we do for all other fields.
2016-06-30 11:43:02 +02:00
197afb413f MDEV-6566 Different INSERT behaviour on bad bytes with and without character set conversion 2015-03-13 16:51:36 +04:00
d13408f8e4 Bug #14668683 ASSERT REC_GET_DELETED_FLAG(REC, PAGE_IS_COMP(PAGE))
Problem:

The function row_upd_changes_ord_field_binary() is used to decide whether to
use row_upd_clust_rec_by_insert() or row_upd_clust_rec().  The function
row_upd_changes_ord_field_binary() does not make use of charset information.
Based on binary comparison it decides that r1 and r2 differ in their ordering
fields.

In the function row_upd_clust_rec_by_insert(), an update is done by delete +
insert.  These operations internally make use of cmp_dtuple_rec_with_match()
to compare records r1 and r2.  This comparison takes place with the use of
charset information.

This means that it is possible for the deleted record to be reused in the
subsequent insert.  In the given scenario, the characters 'a' and 'A' are
considered equal in the my_charset_latin1.  When this happens, the ownership
information of externally stored blobs are not correctly handled.

Solution:

When an update is done by delete followed by insert, disown the relevant
externally stored fields during the delete marking itself (within the same
mtr).  If the insert succeeds, then nothing with respect to blob ownership
needs to be done.  If the insert fails, then the disown done earlier will be
removed when the operation is rolled back.

rb#4479 approved by Marko.
2014-01-30 12:38:13 +05:30