diff options
author | Dmitry Lenev <Dmitry.Lenev@oracle.com> | 2011-06-17 02:02:52 +0400 |
---|---|---|
committer | Dmitry Lenev <Dmitry.Lenev@oracle.com> | 2011-06-17 02:02:52 +0400 |
commit | 291cb58ae5663328a88fafe264a6253e11500a0f (patch) | |
tree | e67274b2e5f858127b8aabb49ed5e503f17aac8d /extra/yassl | |
parent | da9a249b0ab4666d5d7df0114f00efdfb2e8dbc4 (diff) | |
download | mariadb-git-291cb58ae5663328a88fafe264a6253e11500a0f.tar.gz |
Fix for bug #12652385 - "61493: REORDERING COLUMNS
TO POSITION FIRST CAN CAUSE DATA TO BE CORRUPTED".
ALTER TABLE MODIFY/CHANGE ... FIRST did nothing except renaming
columns if new version of the table had exactly the same
structure as the old one (i.e. as result of such statement, names
of columns changed their order as specified but data in columns
didn't). The same thing happened for ALTER TABLE DROP COLUMN/ADD
COLUMN statements which were supposed to produce new version of
table with exactly the same structure as the old version of table.
I.e. in the latter case the result was the same as if old column
was renamed instead of being dropped and new column with default
as value being created.
Both these problems were caused by the fact that ALTER TABLE
implementation incorrectly interpreted both these situations as
simple renaming of columns and assumed that in-place ALTER TABLE
algorithm could have been used for them.
This patch fixes this problem by ensuring that in cases when some
column is moved to the first position or some column is dropped
the default ALTER TABLE algorithm involving table copying is
always used. This is achieved by detecting such situations in
mysql_prepare_alter_table() and setting Alter_info::change_level
to ALTER_TABLE_DATA_CHANGED for them.
Diffstat (limited to 'extra/yassl')
0 files changed, 0 insertions, 0 deletions