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.
mysql-test/r/alter_table.result:
Added test for bug #12652385 - "61493: REORDERING COLUMNS TO
POSITION FIRST CAN CAUSE DATA TO BE CORRUPTED".
mysql-test/t/alter_table.test:
Added test for bug #12652385 - "61493: REORDERING COLUMNS TO
POSITION FIRST CAN CAUSE DATA TO BE CORRUPTED".
sql/sql_table.cc:
Changed mysql_prepare_alter_table() to detect situations in
which we some column moved to the first position or some column
is dropped and ensure that such ALTER TABLE statements won't
be carried out using in-place algorithm. The latter could have
happened before this patch if new version of table had the same
structure as the old one (except the column names).
CLAUSE FAILS OR ABORTS SERVER".
Attempt to re-execute prepared ALTER TABLE statement which
involves .FRM-only changes and also have RENAME clause led
to unwarranted 'Table doesn't exist' error in production
builds and assertion failure for debug builds.
This problem stemmed from the fact that for such ALTER TABLE
mysql_alter_table() code changed table list element for table
to be altered when it tried to re-open table under new name.
Since this change was not reverted back before next
re-execution, it made this statement re-execution unsafe.
This fix addresses this problem by avoiding changing table list
element from the main table list in such a situation. Instead
temporary TABLE_LIST object is used.
mysql-test/r/alter_table.result:
Added test case for bug#11938039 "RE-EXECUTION OF FRM-ONLY
ALTER TABLE WITH RENAME CLAUSE FAILS OR ABORTS SERVER".
mysql-test/t/alter_table.test:
Added test case for bug#11938039 "RE-EXECUTION OF FRM-ONLY
ALTER TABLE WITH RENAME CLAUSE FAILS OR ABORTS SERVER".
sql/sql_table.cc:
Changed mysql_alter_table() not to modify table list element
for the table being altered while re-opening table after
.FRM-only changes. Doing this made .FRM-only ALTER TABLE
which also had RENAME clause unsafe for re-execution.
The problem was that doing ALTER TABLE on a table which had a key
on a TEXT/BLOB column with a prefix longer than the maximum number
of characteres in this column (as per the character set), by mistake,
caused an error (Error 1170 - ER_BLOB_KEY_WITHOUT_LENGTH).
This bug not repeatable in 5.5.
This patch adds a regression test to alter_table.test and
contains no code changes.
table copy".
This patch only adds test case as the bug itself was addressed
by Ramil's fix for bug 50946 "fast index creation still seems
to copy the table".
corruption and crash results
An index creation statement where the index key
is larger/wider than the column it references
should throw an error.
A statement like:
CREATE TABLE t1 (a CHAR(1), PRIMARY KEY (A(255)))
did not error, but a segmentation fault followed when
an insertion was attempted on the table
The partial key validiation clause has been
restructured to (hopefully) better document which
uses of partial keys are valid.
freezes (win) the server
The check for equality was assuming the field object is always
created. If it's not it was de-referencing a NULL pointer.
Fixed to use the data in the create object instead.
An ALTER TABLE statement which added a column and added
a non-partial index on it failed with:
"ERROR 1089 (HY000): Incorrect sub part key; the used
key part isn't a string, the used length is longer than
the key part, or the storage engine doesn't support unique
sub keys"
In a check introduced to fix an earlier bug (no. 26794),
to allow for indices on spatial type columns, the
test expression was flawed (a logical OR was used instead
of a logical AND), which led to this regression.
The code in question does a sanity check on the key, and
the flawed code mistakenly classified any index created
in the way specified above as a partial index. Since
many data types does not allow partial indices, the
statement would fail.
We set up DATE and TIMESTAMP differently in field-creation than we
did in field-MD creation (for CREATE). Admirably, ALTER TABLE
detected this and didn't damage any data, but it did initiate a
full copy/conversion, which we don't really need to do.
Now we describe Field and Create_field the same for those types.
As a result, ALTER TABLE that only changes meta-data (like a
field's name) no longer forces a data-copy when there needn't
be one.
mysql-test/r/alter_table.result:
0 rows should be affected when a meta-data change is enough ALTER TABLE.
mysql-test/t/alter_table.test:
add test-case: show that we don't do a full data-copy on ALTER TABLE
when we don't need to.
sql/field.cc:
Remove Field_str::compare_str_field_flags() (now in Field/Create_field as
field_flags_are_binary().
Correct some field-lengths!
sql/field.h:
Clean-up: use defined constants rather than numeric literals for certain
field-lengths.
Add enquiry-functions binaryp() to classes Field and Create_field.
This replaces field.cc's Field_str::compare_str_field_flags().
The problem was that appending values to the end of an existing
ENUM or SET column was being treated as table data modification,
preventing a immediately (fast) table alteration that occurs when
only table metadata is being modified.
The cause was twofold: adding a enumeration or set members to the
end of the list of valid member values was not being considered
a "compatible" table alteration, and for SET columns, the check
was being done upon the max display length and not the underlying
(pack) length of the field.
The solution is to augment the function that checks wether two ENUM
or SET fields are compatible -- by comparing the pack lengths and
performing a limited comparison of the member values.
mysql-test/r/alter_table.result:
Add test case result for Bug#45567
mysql-test/t/alter_table.test:
Add test case for Bug#45567
sql/field.cc:
Check whether two fields can be considered 'equal' for table
alteration purposes. Fields are equal if they retain the same
pack length and if new members are added to the end of the list.
sql/field.h:
Add comment and remove method.
added ability for TINY[MEDIUM] text fields
to be converted to greater subtype during
alter if necessary(altered charset)
mysql-test/r/alter_table.result:
test result
mysql-test/t/alter_table.test:
test case
sql/sql_table.cc:
added ability for TINY[MEDIUM] text fields
to be converted to greater subtype during
alter if necessary(altered charset)
Problem: mysqld doesn't detect that enum data must be reinserted performing
'ALTER TABLE' in some cases.
Fix: reinsert data altering an enum field if enum values are changed.
mysql-test/r/alter_table.result:
Fix for bug#23113: Different behavior on altering ENUM fields between 5.0 and 5.1
- test result.
mysql-test/t/alter_table.test:
Fix for bug#23113: Different behavior on altering ENUM fields between 5.0 and 5.1
- test case.
sql/field.cc:
Fix for bug#23113: Different behavior on altering ENUM fields between 5.0 and 5.1
- Field_enum::is_equal() introduced, which is called to detect that a field
is changing by 'ALTER TABLE'.
sql/field.h:
Fix for bug#23113: Different behavior on altering ENUM fields between 5.0 and 5.1
- Field_enum::is_equal() introduced, which is called to detect that a field
is changing by 'ALTER TABLE'.
The problem was that PACK_KEYS and MAX_ROWS clause in ALTER TABLE did not trigger
table reconstruction.
The fix is to rebuild a table if PACK_KEYS or MAX_ROWS are specified.
mysql-test/r/alter_table.result:
test result
mysql-test/t/alter_table.test:
test case
sql/sql_table.cc:
The problem was that PACK_KEYS and MAX_ROWS clause in ALTER TABLE did not trigger
table reconstruction.
The fix is to rebuild a table if PACK_KEYS or MAX_ROWS are specified.
The problem was that when comparing tables for a possible
fast alter table, the comparison was being performed using
the parsed information and not the final definition.
The solution is to use the possible final table layout to
compare if a fast alter is possible or not.
mysql-test/include/mix1.inc:
Disable test case for Bug 21704 as it hasn't been fixed.
mysql-test/r/alter_table.result:
Add test case result for Bug#33873
mysql-test/r/innodb_mysql.result:
Update test case result
mysql-test/t/alter_table.test:
Add test case for Bug#33873
sql/sql_table.cc:
Use updated (final) information to compare fields.
INSERT/DELETE/UPDATE followed by ALTER TABLE within LOCK TABLES
may cause table corruption on Windows.
That happens because ALTER TABLE writes outdated shared state
info into index file.
Fixed by removing obsolete workaround.
Affects MyISAM tables on Windows only.
myisam/mi_extra.c:
On windows when mi_extra(HA_EXTRA_PREPARE_FOR_DELETE) is called,
we release external lock and close index file. If we're in LOCK
TABLES, MyISAM state info doesn't get updated until UNLOCK TABLES.
That means when we release external lock and we're in LOCK TABLES,
we may write outdated state info.
As SQL layer closes all table instances, we do not need this
workaround anymore.
mysql-test/r/alter_table.result:
A test case for BUG#29957.
mysql-test/t/alter_table.test:
A test case for BUG#29957.
into olga.mysql.com:/home/igor/mysql-5.1-opt-merge
mysql-test/r/alter_table.result:
Auto merged
mysql-test/r/create.result:
Auto merged
mysql-test/r/innodb_mysql.result:
Auto merged
mysql-test/r/sp.result:
Auto merged
mysql-test/r/user_var.result:
Auto merged
mysql-test/t/alter_table.test:
Auto merged
mysql-test/t/sp.test:
Auto merged
mysql-test/t/strict.test:
Auto merged
mysql-test/t/subselect3.test:
Auto merged
sql/field.h:
Auto merged
sql/handler.h:
Auto merged
sql/item_func.cc:
Auto merged
sql/item_func.h:
Auto merged
sql/mysqld.cc:
Auto merged
sql/sp_head.cc:
Auto merged
sql/sql_base.cc:
Auto merged
sql/sql_class.h:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_update.cc:
Auto merged
mysql-test/r/ps_2myisam.result:
Manual merge.
mysql-test/r/ps_3innodb.result:
Manual merge.
mysql-test/r/ps_4heap.result:
Manual merge.
mysql-test/r/ps_5merge.result:
Manual merge.
mysql-test/r/ps_7ndb.result:
Manual merge.
sql/sql_table.cc:
Manual merge.
sql/sql_view.cc:
Manual merge.
To avoid unnecessary work the mysql_alter_table function takes the
list of table fields and applies all changes to it (drops/moves/renames/etc).
Then this function compares the new list and the old one. If the changes
require only .frm to be modified then the actual data isn't copied. To detect
changes all columns attributes but names are compared. When a column has been
moved and has replaced another column with the same attributes except name
the mysql_alter_table function wrongly decides that two fields has been just
renamed. As a result the data from the moved column and from all columns
after it is not copied.
Now the mysql_alter_table function forces table data copying by setting
the need_copy_table flag when it finds a moved column. The flag is set at
the stage when the modified fields are created.
sql/sql_table.cc:
Bug#28427: Columns were renamed instead of moving by ALTER TABLE.
Now the mysql_alter_table function forces table data copying by setting
the need_copy_table flag when it finds a moved column. The flag is set at
the stage when the modified fields are created.
mysql-test/r/alter_table.result:
Added a test case for the bug#28427: Columns were renamed instead of moving by ALTER TABLE.
mysql-test/t/alter_table.test:
Added a test case for the bug#28427: Columns were renamed instead of moving by ALTER TABLE.
into moonbone.local:/mnt/gentoo64/work/test-5.1-opt-mysql
mysql-test/r/func_gconcat.result:
Auto merged
mysql-test/t/func_gconcat.test:
Auto merged
sql/item_sum.cc:
Auto merged
sql/sql_base.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/table.h:
Auto merged
mysql-test/r/alter_table.result:
Manual merge
mysql-test/t/alter_table.test:
Manual merge
sql/sql_table.cc:
Manual merge
mode.
When a new DATE/DATETIME field without default value is being added by the
ALTER TABLE the '0000-00-00' value is used as the default one. But it wasn't
checked whether such value was allowed by the set sql mode. Due to this
'0000-00-00' values was allowed for DATE/DATETIME fields even in the
NO_ZERO_DATE mode.
Now the mysql_alter_table() function checks whether the '0000-00-00' value
is allowed for DATE/DATETIME fields by the set sql mode.
The new error_if_not_empty flag is used in the mysql_alter_table() function
to indicate that it should abort if the table being altered isn't empty.
The new new_datetime_field field is used in the mysql_alter_table() function
for error throwing purposes.
The new error_if_not_empty parameter is added to the copy_data_between_tables()
function to indicate the it should return error if the source table isn't empty.
mysql-test/t/alter_table.test:
Added a test case for the bug#27507: Wrong DATETIME value was allowed by
ALTER TABLE in the NO_ZERO_DATE mode.
mysql-test/r/alter_table.result:
Added a test case for the bug#27507: Wrong DATETIME value was allowed by
ALTER TABLE in the NO_ZERO_DATE mode.
sql/sql_table.cc:
Bug#27507: Wrong DATETIME value was allowed by ALTER TABLE in the NO_ZERO_DATE
mode.
Now the mysql_alter_table() function checks whether the '0000-00-00' value
is allowed for DATE/DATETIME fields by the set sql mode.
The new error_if_not_empty flag is used in the mysql_alter_table() function
to indicate that it should abort if the table being altered isn't empty.
The new new_datetime_field field is used in the mysql_alter_table() function
for error throwing purposes.
The new error_if_not_empty parameter is added to the copy_data_between_tables()
function to indicate the it should return error if the source table isn't empty.
and invalidation in the most general case (non-temporary table and
not simple RENAME or ENABLE/DISABLE KEYS or partitioning command).
See comment for sql/sql_table.cc for more information.
These changes are prerequisite for 5.1 version of fix for bug #23667
"CREATE TABLE LIKE is not isolated from alteration by other connections"
mysql-test/include/mix1.inc:
Extended coverage for behavior of ALTER TABLE statement under LOCK TABLES,
which should be consistent across all platforms and for all engines.
mysql-test/r/alter_table-big.result:
Changed test for bug #25044 to use @@debug and injected sleeps
infrastructure. Extended test coverage for ALTER TABLE's behavior
under concurrency.
mysql-test/r/alter_table.result:
Extended coverage for behavior of ALTER TABLE statement under LOCK TABLES,
which should be consistent across all platforms and for all engines.
mysql-test/r/innodb_mysql.result:
Extended coverage for behavior of ALTER TABLE statement under LOCK TABLES,
which should be consistent across all platforms and for all engines.
mysql-test/t/alter_table-big.test:
Changed test for bug #25044 to use @@debug and injected sleeps
infrastructure. Extended test coverage for ALTER TABLE's behavior
under concurrency.
mysql-test/t/alter_table.test:
Extended coverage for behavior of ALTER TABLE statement under LOCK TABLES,
which should be consistent across all platforms and for all engines.
sql/mysql_priv.h:
Made functions reopen_table() and close_handle_and_leave_table_as_lock()
available outside of sql_base.cc file.
Changed close_data_tables() in such way that after closing handler
for the table it leaves TABLE object for it in table cache not as
placeholder for ordinary name-lock but as placeholder for an exclusive
name-lock. Renamed this routine to close_data_files_and_morph_locks().
sql/sql_base.cc:
Made functions reopen_table() and close_handle_and_leave_table_as_lock()
available outside of sql_base.cc file.
Changed close_data_tables() in such way that after closing handler
for the table it leaves TABLE object for it in table cache not as
placeholder for ordinary name-lock but as placeholder for an exclusive
name-lock. Renamed this routine to close_data_files_and_morph_locks().
Also adjusted it so it can work properly not only in LOCK TABLES mode.
sql/sql_table.cc:
Changed the way in which ALTER TABLE implementation handles table
locking and invalidation in the most general case (non-temporary table
and not simple RENAME or ENABLE/DISABLE KEYS or partitioning command)
Now after preparing new version of the table we:
1) Wait until all other threads close old version of table.
2) Close instances of table open by this thread and replace them
with exclusive name-locks.
3) Rename the old table to a temp name, rename the new one to the
old name.
4) If we are under LOCK TABLES and don't do ALTER TABLE ... RENAME
we reopen new version of table.
5) Write statement to the binary log.
6) If we are under LOCK TABLES and do ALTER TABLE ... RENAME we
remove name-locks from list of open tables and table cache.
7) If we are not not under LOCK TABLES we rely on close_thread_tables()
call to remove name-locks from table cache and list of open table.
Such approach:
a) Eliminates possibility for concurrent statement to sneak in and get
access to the new version of the table before ALTER TABLE gets logged
into binary log.
b) Ensures that ALTER TABLE behaves under LOCK TABLES in the same way
on all platforms and for all engines (in 5.0 this was not true)
c) Preserves nice invariant that if table is open in some connection
there is a guarantee that .FRM file for this table exists and is
properly named.
into pilot.blaudden:/home/msvensson/mysql/mysql-5.1-maint
mysql-test/r/alter_table.result:
Auto merged
mysql-test/t/alter_table.test:
Auto merged
sql/sql_table.cc:
Auto merged
into pilot.blaudden:/home/msvensson/mysql/mysql-5.1-maint
mysql-test/r/alter_table.result:
Auto merged
mysql-test/t/alter_table.test:
Auto merged
sql/sql_table.cc:
Auto merged
into pilot.blaudden:/home/msvensson/mysql/bug25262/my51-bug25262
mysql-test/r/alter_table.result:
Manual merge
mysql-test/t/alter_table.test:
Manual merge
sql/sql_table.cc:
Manual merge, auto_increment_value variable has moved into "stats"
It was syntactically correct to define
spatial keys over parts of columns (e.g.
ALTER TABLE t1 ADD x GEOMETRY NOT NULL,
ADD SPATIAL KEY (x(32))).
This may lead to undefined results and/or
interpretation.
Fixed by not allowing partial column
specification in a SPATIAL index definition.
mysql-test/r/alter_table.result:
Bug #26794: 5.1 part
test case
mysql-test/r/gis-rtree.result:
Bug #26794: 5.1 part
updated the tests to the new syntax
mysql-test/t/alter_table.test:
Bug #26794: 5.1 part
test case
mysql-test/t/gis-rtree.test:
Bug #26794: 5.1 part
updated the tests to the new syntax
sql/sql_table.cc:
Bug #26794: 5.1 part
Disable defining SPATIAL KEYS with sub-key parts
Different set of conditions is used to verify
the validity of index definitions over a GEOMETRY
column in ALTER TABLE and CREATE TABLE.
The difference was on how sub-keys notion validity
is checked.
Fixed by extending the CREATE TABLE condition to
support the cases allowed in ALTER TABLE.
Made the SHOW CREATE TABLE not to display spatial
indexes using the sub-key notion.
mysql-test/r/alter_table.result:
Bug #26794: test case
mysql-test/r/gis-rtree.result:
Bug #26794: fixed SHOW CREATE TABLE output.
mysql-test/t/alter_table.test:
Bug #26794: test case
sql/field.cc:
Bug #26794: Allow sub-keys for GEOMETRY
sql/sql_show.cc:
Bug #26794: Don't show sub-key notion
in SHOW CREATE TABLE for SPATIAL indexes.
sql/sql_table.cc:
Bug #26794: Allow sub-keys for GEOMETRY
into magare.gmz:/home/kgeorge/mysql/work/B26794-5.1-opt
mysql-test/r/gis-rtree.result:
Auto merged
sql/field.cc:
Auto merged
sql/sql_show.cc:
Auto merged
sql/sql_table.cc:
Auto merged
mysql-test/r/alter_table.result:
tests merge
mysql-test/t/alter_table.test:
tests merge
Different set of conditions is used to verify
the validity of index definitions over a GEOMETRY
column in ALTER TABLE and CREATE TABLE.
The difference was on how sub-keys notion validity
is checked.
Fixed by extending the CREATE TABLE condition to
support the cases allowed in ALTER TABLE.
Made the SHOW CREATE TABLE not to display spatial
indexes using the sub-key notion.
mysql-test/r/alter_table.result:
Bug #26794: test case
mysql-test/r/gis-rtree.result:
Bug #26794: fixed SHOW CREATE TABLE output.
mysql-test/t/alter_table.test:
Bug #26794: test case
sql/field.cc:
Bug #26794: Allow sub-keys for GEOMETRY
sql/sql_show.cc:
Bug #26794: Don't show sub-key notion
in SHOW CREATE TABLE for SPATIAL indexes.
sql/sql_table.cc:
Bug #26794: Allow sub-keys for GEOMETRY
- Try to copy the autoincrement value when altering the table
mysql-test/r/alter_table.result:
Update test result
mysql-test/t/alter_table.test:
Add test case as described in bug report
sql/sql_table.cc:
Try to copy the autoincrement value when altering the table
into weblab.(none):/home/marcsql/TREE/mysql-5.1-24562-merge
mysql-test/r/alter_table.result:
Auto merged
mysql-test/t/alter_table.test:
Auto merged
sql/sql_yacc.yy:
Auto merged
WL#3681 (ALTER TABLE ORDER BY)
Before this fix, the ALTER TABLE statement implemented an ORDER BY option
with the following characteristics :
1) The order by clause accepts a list of criteria, with optional ASC or
DESC keywords
2) Each criteria can be a general expression, involving operators,
native functions, stored functions, user defined functions, subselects ...
With this fix :
1) has been left unchanged, since it's a de-facto existing feature,
that was already present in the code base and partially covered in the test
suite. Code coverage for ASC and DESC was missing and has been improved.
2) has been changed to limit the kind of criteria that are permissible:
now only a column name is valid.
mysql-test/r/alter_table.result:
Prevent ALTER TABLE ORDER BY clauses to use general expressions.
mysql-test/t/alter_table.test:
Prevent ALTER TABLE ORDER BY clauses to use general expressions.
sql/sql_yacc.yy:
Prevent ALTER TABLE ORDER BY clauses to use general expressions.
into mysql.com:/home/svoj/devel/mysql/BUG23404/mysql-5.1-engines
mysql-test/r/alter_table.result:
Auto merged
mysql-test/t/alter_table.test:
Auto merged
sql/sql_parse.cc:
Auto merged
into mysql.com:/home/svoj/devel/mysql/BUG23404/mysql-5.0-engines
mysql-test/r/alter_table.result:
Auto merged
mysql-test/t/alter_table.test:
Auto merged
sql/sql_parse.cc:
SCCS merged
table
ROW_FORMAT option is lost during CREATE/DROP INDEX.
This fix forces CREATE/DROP INDEX to retain ROW_FORMAT by instructing
mysql_alter_table() that ROW_FORMAT is not used during creating/dropping
indexes.
mysql-test/r/alter_table.result:
A test case for bug#23404.
mysql-test/t/alter_table.test:
A test case for bug#23404.
sql/sql_parse.cc:
CREATE/DROP INDEX must not change ROW_FORMAT. Setting create_info.row_type
to ROW_TYPE_NOT_USED informs mysql_alter_table that ROW_FORMAT was not
used during alteration, and thus must be retained.
into example.com:/work/bug22369-v2/my51
mysql-test/r/alter_table.result:
Auto merged
mysql-test/r/grant.result:
Auto merged
mysql-test/t/grant.test:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_table.cc:
Auto merged
mysql-test/t/alter_table.test:
manual merge
with other alterations causes lost tables
Using RENAME clause combined with other clauses of ALTER TABLE led to
data loss (the data was there but not accessible). This could happen if the
changes do not change the table much. Adding and droppping of fields and
indices was safe. Renaming a column with MODIFY or CHANGE was unsafe operation,
if the actual column didn't change (changing from int to int, which is a noop)
Depending on the storage engine (SE) the behavior is different:
1)MyISAM/MEMORY - the ALTER TABLE statement completes
without any error but next SELECT against the new table fails.
2)InnoDB (and every other transactional table) - The ALTER TABLE statement
fails. There are the the following files in the db dir -
`new_table_name.frm` and a temporary table's frm. If the SE is file
based, then the data and index files will be present but with the old
names. What happens is that for InnoDB the table is not renamed in the
internal DDIC.
Fixed by adding additional call to mysql_rename_table() method, which should
not include FRM file rename, because it has been already done during file
names juggling.
mysql-test/r/alter_table.result:
update result
mysql-test/r/grant.result:
update result
mysql-test/t/alter_table.test:
2006/11/29 11:46:23+01:00 andrey@example.com +44 -9
Error to bug number
Added test case for #22369: Alter table rename combined
with other alterations causes lost tables
mysql-test/t/grant.test:
add test for bug#22369 - alter table was missing check
for DROP_ACL when ALTER_RENAME clause is specified. Synchronise
with RENAME TABLE DDL.
sql/mysql_priv.h:
Add a new flag for mysql_rename_table()
sql/sql_parse.cc:
To be consistent with SQLCOM_RENAME_TABLE, SQLCOM_ALTER_TABLE has
to check for DROP_ACL if there is ALTER_RENAME flag set.
sql/sql_table.cc:
ALTER_RENAME, the data and index files weren't renamed in the engine
but only the FRM was new, when the tables old and new tables are compatible.
In the chain of FRM renames we add a call to mysql_rename_table() which should
instruct the engine to rename the table but not rename the FRM.
This bug was there only in 5.1 branch. 4.1 and 5.0 always do copy data on RENAME
if there are more clauses than just rename.
into example.com:/work/bug24395-v2/my51
mysql-test/r/alter_table.result:
Auto merged
mysql-test/t/alter_table.test:
Auto merged
storage/myisam/mi_open.c:
Auto merged
sql/sql_table.cc:
manual merge
into example.com:/work/bug24395-v2/my50
fix for bug#24395 merged into 5.0
mysql-test/t/alter_table.test:
Auto merged
myisam/mi_open.c:
merge into 5.0 by using macroses available in 5.0
mysql-test/r/alter_table.result:
manual merge
sql/sql_table.cc:
manual merge
Added else clause of
if (new_table && !new_table->file->is_view)
This else clauses does keys management on the live table, thus we have
to force other threads to reopen the table.
