The ALL/ANY subqueries are the subject of MIN/MAX optimization. The matter
of this optimization is to embed MIN() or MAX() function into the subquery
in order to get only one row by which we can tell whether the expression
with ALL/ANY subquery is true or false.
But when it is applied to a subquery like 'select a_constant' the reported bug
occurs. As no tables are specified in the subquery the do_select() function
isn't called for the optimized subquery and thus no values have been added
to a MIN()/MAX() function and it returns NULL instead of a_constant.
This leads to a wrong query result.
For the subquery like 'select a_constant' there is no reason to apply
MIN/MAX optimization because the subquery anyway will return at most one row.
Thus the Item_maxmin_subselect class is more appropriate for handling such
subqueries.
The Item_in_subselect::single_value_transformer() function now checks
whether tables are specified for the subquery. If no then this subselect is
handled like a UNION using an Item_maxmin_subselect object.
mysql-test/t/subselect.test:
Added test case for bug#16302: Quantified subquery without any tables gives wrong results
mysql-test/r/subselect.result:
Added test case for bug#16302: Quantified subquery without any tables gives wrong results
sql/item_subselect.cc:
Fixed bug#16302: Quantified subquery without any tables gives wrong results
The Item_in_subselect::single_value_transformer() function now checks
whether tables are specified for the subquery. If no then this subselect is
handled like a UNION using an Item_maxmin_subselect object.
into macbook.gmz:/Users/kgeorge/mysql/work/B14553-5.0-opt
mysql-test/r/odbc.result:
Auto merged
sql/sql_select.cc:
Auto merged
mysql-test/r/rpl_insert_id.result:
merge the test at the end of 4.1 test
mysql-test/t/rpl_insert_id.test:
merge the test at the end of 4.1 test
sql/sql_class.cc:
merged
sql/sql_class.h:
merged
To make MySQL compatible with some ODBC applications, you can find
the AUTO_INCREMENT value for the last inserted row with the following query:
SELECT * FROM tbl_name WHERE auto_col IS NULL.
This is done with a special code that replaces 'auto_col IS NULL' with
'auto_col = LAST_INSERT_ID'.
However this also resets the LAST_INSERT_ID to 0 as it uses it for a flag
so as to ensure that only the first SELECT ... WHERE auto_col IS NULL
after an INSERT has this special behaviour.
In order to avoid resetting the LAST_INSERT_ID a special flag is introduced
in the THD class. This flag is used to restrict the second and subsequent
SELECTs instead of LAST_INSERT_ID.
mysql-test/r/odbc.result:
test suite for the bug
mysql-test/r/rpl_insert_id.result:
test for the fix in replication
mysql-test/t/odbc.test:
test suite for the bug
mysql-test/t/rpl_insert_id.test:
test for the fix in replication
sql/sql_class.cc:
initialize the flag
sql/sql_class.h:
flag's declaration and set code when setting the last_insert_id
sql/sql_select.cc:
the special flag is used instead of last_insert_id
mysql-test/r/myisam.result:
Fix test results.
mysql-test/t/myisam.test:
In 5.0 show create table also outputs data directory.
For the test for Bug#8706 it's MYSQLTEST_VARDIR, and there is no way
to replace it with anything else in test output.
into bodhi.local:/opt/local/work/mysql-5.0-runtime-merge-41
myisam/mi_create.c:
Auto merged
mysql-test/r/myisam.result:
Auto merged
mysql-test/t/myisam.test:
Auto merged
sql/item_timefunc.cc:
Auto merged
sql/sql_class.cc:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_trigger.cc:
Auto merged
support-files/mysql.spec.sh:
Auto merged
mysql-test/r/federated.result:
Manual merge.
mysql-test/t/federated.test:
Manual merge.
into bodhi.local:/opt/local/work/mysql-5.0-runtime-merge-41
BitKeeper/etc/ignore:
auto-union
libmysqld/Makefile.am:
Auto merged
myisam/mi_create.c:
Auto merged
mysql-test/r/date_formats.result:
Auto merged
mysql-test/t/date_formats.test:
Auto merged
sql/Makefile.am:
Auto merged
sql/item_timefunc.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/opt_range.cc:
Auto merged
sql/sql_class.h:
Auto merged
support-files/mysql.spec.sh:
Auto merged
mysql-test/r/myisam.result:
Manual merge.
mysql-test/t/myisam.test:
Manual merge.
sql/set_var.cc:
Manual merge.
sql/set_var.h:
Manual merge.
sql/sql_cache.cc:
Manual merge.
sql/sql_class.cc:
Manual merge.
into bodhi.local:/opt/local/work/mysql-5.0-runtime
sql/ha_ndbcluster.cc:
Auto merged
sql/item.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_table.cc:
Auto merged
sql/sql_yacc.yy:
Auto merged
sql/sql_update.cc:
Manual merge.
Adding test case.
item_strfunc.cc:
bug#11728 string function LEFT, strange undocumented behaviour
Fixing LEFT and RIGHT return NULL if the second
argument is NULL.
sql/item_strfunc.cc:
bug#11728 string function LEFT, strange undocumented behaviour
Fixing LEFT and RIGHT return NULL if the second
argument is NULL.
mysql-test/t/func_str.test:
Adding test case.
mysql-test/r/func_str.result:
Adding test case.
Fix random failures in test 'wait_timeout' that depend on exact timing.
1. Force a reconnect initially if necessary, as otherwise slow startup
might have caused a connection timeout before the test can even start.
2. Explicitly disconnect the first connection to remove confusion about
which connection aborts from timeout, causing test failure.
mysql-test/r/wait_timeout.result:
Fix two races in test.
mysql-test/t/wait_timeout.test:
Fix two races in test.
into olga.mysql.com:/home/igor/mysql-5.0-opt
mysql-test/r/func_str.result:
Auto merged
mysql-test/t/func_str.test:
Auto merged
sql/item.h:
Auto merged
sql/item_strfunc.cc:
Auto merged
sql/item_strfunc.h:
Auto merged
dropping/creating tables".
The bug could lead to a crash when multi-delete statements were
prepared and used with temporary tables.
The bug was caused by lack of clean-up of multi-delete tables before
re-execution of a prepared statement. In a statement like
DELETE t1 FROM t1, t2 WHERE ... the first table list (t1) is
moved to lex->auxilliary_table_list and excluded from lex->query_tables
or select_lex->tables. Thus it was unaccessible to reinit_stmt_before_use
and not cleaned up before re-execution of a prepared statement.
mysql-test/r/ps.result:
Updated test results (Bug#19399)
mysql-test/t/ps.test:
A test case for Bug#19399 "Stored Procedures 'Lost Connection' when
dropping/creating tables": test that multi-delete
tables are cleaned up properly before re-execution.
sql/sql_lex.cc:
Always initialize auxilliary_table_list when we initialize the lex:
this way we don't have to check that lex->sql_command equals to
SQLCOM_DELETE_MULTI whenever we need to access auxilliary_table_list.
In particular, in reinit_stmt_before_use we can simply check that
auxilliary_table_list is not NULL and clean it up if the check returns
a true value.
sql/sql_prepare.cc:
Move the one table clean-up functionality to a method of st_table_list.
Clean up auxiliary_table_list if it's not empty.
sql/table.cc:
Implement st_table_list::reinit_before_use().
sql/table.h:
Declare st_table_list::reinit_before_use().
The implementation of the method Item_func_reverse::val_str
for the REVERSE function modified the argument of the function.
This led to wrong results for expressions that contained
REVERSE(ref) if ref occurred somewhere else in the expressions.
mysql-test/r/func_str.result:
Added a test case for bug #18243.
mysql-test/t/func_str.test:
Added a test case for bug #18243.
sql/item_strfunc.cc:
Fixed bug #18243.
The implementation of the method Item_func_reverse::val_str
for the REVERSE function modified the argument of the function.
This led to wrong results for expressions that contained
REVERSE(ref) if ref occurred somewhere else in the expressions.
The implementation of Item_func_reverse::val_str has been changed
to make the argument intact.
sql/item_strfunc.h:
Fixed bug #18243.
Added tmp_value to the Item_func_reverse class to store
the result of the function. It erroneously replaced the
argument before this fix.
a too large value": the bug was that if MySQL generated a value for an
auto_increment column, based on auto_increment_* variables, and this value
was bigger than the column's max possible value, then that max possible
value was inserted (after issuing a warning). But this didn't honour
auto_increment_* variables (and so could cause conflicts in a master-master
replication where one master is supposed to generated only even numbers,
and the other only odd numbers), so now we "round down" this max possible
value to honour auto_increment_* variables, before inserting it.
mysql-test/r/rpl_auto_increment.result:
result update. Before the fix, the result was that master inserted 127 in t1
(which didn't honour auto_increment_* variables!),
instead of failing with "duplicate key 125" like now.
mysql-test/t/rpl_auto_increment.test:
Test for BUG#20524 "auto_increment_* not observed when inserting
a too large value".
We also check the pathological case (table t2) where it's impossible to
"round down".
The fixer of BUG#20573 will be able to use table t2 for testing his fix.
sql/handler.cc:
If handler::update_auto_increment() generates a value larger than the field's
max possible value, we used to simply insert this max possible value
(after pushing a warning). Now we "round down" this max possible value to
honour auto_increment_* variables (if at all possible), before trying the
insertion.
into mysql.com:/home/dlenev/mysql-5.0-bg18437-3
mysql-test/t/federated.test:
Auto merged
sql/ha_ndbcluster.cc:
Auto merged
sql/item.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/sql_delete.cc:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_table.cc:
Auto merged
sql/sql_trigger.cc:
Auto merged
sql/sql_update.cc:
Auto merged
mysql-test/r/federated.result:
Manual merge.
Adding decimal "digits" in multiplication resulted in signed overflow and
producing wrong results.
Fixed by using large enough buffers and intermediary result types :
dec2 (currently longlong) to hold result of adding decimal "digits"
(currently int32).
mysql-test/r/select.result:
Bug #20569 Garbage in DECIMAL results from some mathematical functions
* test suite for the bug
mysql-test/t/select.test:
Bug #20569 Garbage in DECIMAL results from some mathematical functions
* test suite for the bug
strings/decimal.c:
Bug #20569 Garbage in DECIMAL results from some mathematical functions
* fixed the overflow in adding decimal "digits"
into xiphis.org:/home/antony/work2/p2-bug8706.3-merge-5.0
configure.in:
Auto merged
mysql-test/r/federated.result:
Auto merged
mysql-test/r/func_sapdb.result:
Auto merged
mysql-test/r/func_time.result:
Auto merged
mysql-test/r/symlink.result:
Auto merged
mysql-test/t/federated.test:
Auto merged
mysql-test/t/func_sapdb.test:
Auto merged
mysql-test/t/func_time.test:
Auto merged
sql/item_timefunc.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
"temporary table with data directory option fails"
myisam should not use user-specified table name when creating
temporary tables and use generated connection specific real name.
Test included.
myisam/mi_create.c:
Bug#8706
When creating a temporary table with directory override, ensure that
the real filename is using the hidden temporary name otherwise
multiple clients cannot have same named temporary tables without
conflict.
mysql-test/r/myisam.result:
Bug#8706
Test for bug
mysql-test/t/myisam.test:
Bug#8706
Test for bug
auto_increment breaks binlog":
if slave's table had a higher auto_increment counter than master's (even
though all rows of the two tables were identical), then in some cases,
REPLACE and INSERT ON DUPLICATE KEY UPDATE failed to replicate
statement-based (it inserted different values on slave from on master).
write_record() contained a "thd->next_insert_id=0" to force an adjustment
of thd->next_insert_id after the update or replacement. But it is this
assigment introduced indeterminism of the statement on the slave, thus
the bug. For ON DUPLICATE, we replace that assignment by a call to
handler::adjust_next_insert_id_after_explicit_value() which is deterministic
(does not depend on slave table's autoinc counter). For REPLACE, this
assignment can simply be removed (as REPLACE can't insert a number larger
than thd->next_insert_id).
We also move a too early restore_auto_increment() down to when we really know
that we can restore the value.
mysql-test/r/rpl_insert_id.result:
result update, without the bugfix, slave's "3 350" were "4 350".
mysql-test/t/rpl_insert_id.test:
test for BUG#20188 "REPLACE or ON DUPLICATE KEY UPDATE in
auto_increment breaks binlog".
There is, in this order:
- a test of the bug for the case of REPLACE
- a test of basic ON DUPLICATE KEY UPDATE functionality which was not
tested before
- a test of the bug for the case of ON DUPLICATE KEY UPDATE
sql/handler.cc:
the adjustment of next_insert_id if inserting a big explicit value, is
moved to a separate method to be used elsewhere.
sql/handler.h:
see handler.cc
sql/sql_insert.cc:
restore_auto_increment() means "I know I won't use this autogenerated
autoincrement value, you are free to reuse it for next row". But we were
calling restore_auto_increment() in the case of REPLACE: if write_row() fails
inserting the row, we don't know that we won't use the value, as we are going to
try again by doing internally an UPDATE of the existing row, or a DELETE
of the existing row and then an INSERT. So I move restore_auto_increment()
further down, when we know for sure we failed all possibilities for the row.
Additionally, in case of REPLACE, we don't need to reset THD::next_insert_id:
the value of thd->next_insert_id will be suitable for the next row.
In case of ON DUPLICATE KEY UPDATE, resetting thd->next_insert_id is also
wrong (breaks statement-based binlog), but cannot simply be removed, as
thd->next_insert_id must be adjusted if the explicit value exceeds it.
We now do the adjustment by calling
handler::adjust_next_insert_id_after_explicit_value() (which, contrary to
thd->next_insert_id=0, does not depend on the slave table's autoinc counter,
and so is deterministic).
into mysql.com:/home/tomash/src/mysql_ab/mysql-5.0-bug20570
sql/item_strfunc.cc:
Auto merged
sql/item_strfunc.h:
Auto merged
sql/sql_yacc.yy:
Auto merged
mysql-test/r/view_grant.result:
Manual merge.
mysql-test/t/view_grant.test:
Manual merge.
run at startup"
The server returned an error when trying to execute init-file with a
stored procedure that could return multiple result sets to the client.
A stored procedure can return multiple result sets if it contains
PREPARE, SELECT, SHOW and similar statements.
The fix is to set client_capabilites|=CLIENT_MULTI_RESULTS in
sql_parse.cc:handle_bootstrap(). There is no "client" really, so
nothing is ever sent. This makes init-file feature behave consistently:
the prepared statements that can be called directly in the init-file
can be used in a stored procedure too.
Re-committed the patch originally submitted by Per-Erik after review.
mysql-test/Makefile.am:
Fix re-make without make clean.
mysql-test/r/init_connect.result:
Updated results (a test case for Bug#17843)
mysql-test/r/init_file.result:
Updated results (a test case for Bug#17843)
mysql-test/std_data/init_file.dat:
Add test coverage for new features added in 5.0. Note, that what can
be done in init_file is very limited as it does not support any other
delimiter except ';' -- only "one liners" and no multiple statement
procedures. Also, this is executed with a dummy user "boot@", which
calls for the use of DEFINER clause.
mysql-test/t/init_connect.test:
Add test coverage for new features added in 5.0.
mysql-test/t/init_file.test:
Add test coverage for new features added in 5.0 --
stored routines, views, triggers. The actual tests are in
std_data/init_file.dat, here we just check the results and clean up.
sql/sql_class.cc:
Initialize Security_context::priv_host to an empty string:
when executing an init-file, sql_parse.cc:get_default_definer()
will use this for the value of the definer if it's not set in the query.
sql/sql_parse.cc:
Set CLIENT_MULTI_RESULTS in handle_bootstrap(), to make prepared
statements work in stored procedures called from init-file.
(implemented by by Josh Chamas)
libmysqld/Makefile.am:
Adding new source file
mysql-test/r/date_formats.result:
Adding test case
mysql-test/t/date_formats.test:
Adding test case
sql/Makefile.am:
Adding new source file
BitKeeper/etc/ignore:
Added libmysqld/sql_locale.cc to the ignore list
sql/item_timefunc.cc:
Using current locale data, instead of hard coded English names.
sql/mysql_priv.h:
Adding new type MY_LOCALE, and declaring new global variables.
sql/set_var.cc:
Adding "lc_time_names" system variable.
sql/set_var.h:
Adding "lc_time_names" system variable.
sql/sql_cache.cc:
Adding lc_time_names as a query cache flag.
sql/sql_class.cc:
Setting default locale to en_US
sql/sql_class.h:
Adding locale variable into system_variables.
sql/sql_locale.cc:
Adding new file with locale data for various languages
When compiling INSERT statements the check whether columns are provided values
depends on the flag whether a field is used in that query (Field::query_id).
However the check for updatability of VIEW columns (check_view_insertability())
was calling fix_fields() and thus setting the Field::query_id even for the
view fields that are not referenced in the current INSERT statement.
So the correct check for columns without default values
( check_that_all_fields_are_given_values() ) is assuming that all the VIEW
columns were mentioned in the INSERT field list and was issuing no
warnings or errors.
Fixed check_view_insertability() to turn off the flag whether or not to set
Field::query_id (THREAD::set_query_id) before calling fix fields and restore
it when it's done.
mysql-test/r/view.result:
Bug #16110: insert permitted into view col w/o default value
* test case
mysql-test/t/view.test:
Bug #16110: insert permitted into view col w/o default value
* test case
sql/sql_insert.cc:
Bug #16110: insert permitted into view col w/o default value
* avoid setting the "field used" flag for fields when checking view columns
for updatability.
* a missing DBUG_RETURN added.
into mysql.com:/home/gluh/MySQL/Merge/5.0-kt
sql/item.cc:
Auto merged
sql/item.h:
Auto merged
sql/sql_acl.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_show.cc:
Auto merged
sql/sql_yacc.yy:
Auto merged
sql/table.cc:
Auto merged
tests/mysql_client_test.c:
Auto merged
invoker name
The bug was fixed similar to how context switch is handled in
Item_func_sp::execute_impl(): we store pointer to current
Name_resolution_context in Item_func_current_user class, and use
its Security_context in Item_func_current_user::fix_fields().
mysql-test/r/view_grant.result:
Add result for bug#20570.
mysql-test/t/view_grant.test:
Add test case for bug#20570.
sql/item_create.cc:
Remove create_func_current_user(), as it is not used for automatic
function creation.
sql/item_create.h:
Remove prototype for create_func_current_user().
sql/item_strfunc.cc:
Add implementations for Item_func_user::init(),
Item_func_user::fix_fields() and
Item_func_current_user::fix_fields() methods. The latter uses
Security_context from current Name_resolution_context, if one is
defined.
sql/item_strfunc.h:
Move implementation of CURRENT_USER() out of Item_func_user to
to new Item_func_current_user class. For both classes calculate
user name in fix_fields() method.
For Item_func_current_user add context field to store
Name_resolution_context in effect.
sql/sql_yacc.yy:
Pass current Name_resolution_context to Item_func_current_user.
NDB table".
SQL-layer was not marking fields which were used in triggers as such. As
result these fields were not always properly retrieved/stored by handler
layer. So one might got wrong values or lost changes in triggers for NDB,
Federated and possibly InnoDB tables.
This fix solves the problem by marking fields used in triggers
appropriately.
Also this patch contains the following cleanup of ha_ndbcluster code:
We no longer rely on reading LEX::sql_command value in handler in order
to determine if we can enable optimization which allows us to handle REPLACE
statement in more efficient way by doing replaces directly in write_row()
method without reporting error to SQL-layer.
Instead we rely on SQL-layer informing us whether this optimization
applicable by calling handler::extra() method with
HA_EXTRA_WRITE_CAN_REPLACE flag.
As result we no longer apply this optimzation in cases when it should not
be used (e.g. if we have on delete triggers on table) and use in some
additional cases when it is applicable (e.g. for LOAD DATA REPLACE).
Finally this patch includes fix for bug#20728 "REPLACE does not work
correctly for NDB table with PK and unique index".
This was yet another problem which was caused by improper field mark-up.
During row replacement fields which weren't explicity used in REPLACE
statement were not marked as fields to be saved (updated) so they have
retained values from old row version. The fix is to mark all table
fields as set for REPLACE statement. Note that in 5.1 we already solve
this problem by notifying handler that it should save values from all
fields only in case when real replacement happens.
include/my_base.h:
Added HA_EXTRA_WRITE_CAN_REPLACE, HA_EXTRA_WRITE_CANNOT_REPLACE - new
parameters for ha_extra() method. We use them to inform handler that
write_row() which tries to insert new row into the table and encounters
some already existing row with same primary/unique key can replace old
row with new row instead of reporting error.
mysql-test/r/federated.result:
Additional test for bug#18437 "Wrong values inserted with a before update
trigger on NDB table".
mysql-test/r/ndb_replace.result:
Added test for bug #20728 "REPLACE does not work correctly for NDB table
with PK and unique index". Updated wrong results from older test.
mysql-test/t/federated.test:
Additional test for bug#18437 "Wrong values inserted with a before update
trigger on NDB table".
mysql-test/t/ndb_replace.test:
Added test for bug #20728 "REPLACE does not work correctly for NDB table
with PK and unique index".
sql/ha_ndbcluster.cc:
We no longer rely on reading LEX::sql_command value in handler in order
to determine if we can enable optimization which allows us to handle REPLACE
statement in more efficient way by doing replaces directly in write_row()
method without reporting error to SQL-layer.
Instead we rely on SQL-layer informing us whether this optimization
applicable by calling handler::extra() method with
HA_EXTRA_WRITE_CAN_REPLACE flag.
As result we no longer apply this optimization in cases when it should not
be used (e.g. if we have on delete triggers on table) and use in some
additional cases when it is applicable (e.g. for LOAD DATA REPLACE).
sql/item.cc:
Item_trigger_field::setup_field():
Added comment explaining why we don't set Field::query_id in this method.
sql/mysql_priv.h:
mysql_alter_table() function no longer takes handle_duplicates argument.
Added declaration of mark_fields_used_by_triggers_for_insert_stmt() function.
sql/sql_delete.cc:
Mark fields which are used by ON DELETE triggers so handler will retrieve
values for these fields.
sql/sql_insert.cc:
Explicitly inform handler that we are doing REPLACE (using ha_extra() method)
in cases when it can promote insert operation done by write_row() to replace.
Also when we do REPLACE we want to store values for all columns so we should
inform handler about it.
Finally we should mark fields used by ON UPDATE/ON DELETE triggers as such
so handler can properly retrieve/restore values in these fields during
execution of REPLACE and INSERT ... ON DUPLICATE KEY UPDATE statements.
sql/sql_load.cc:
Explicitly inform handler that we are doing LOAD DATA REPLACE (using
ha_extra() method) in cases when it can promote insert operation done by
write_row() to replace.
Also when we do replace we want to save (replace) values for all columns
so we should inform handler about it.
Finally to properly execute LOAD DATA for table with triggers we should
mark fields used by ON INSERT triggers as such so handler can properly
store values for these fields.
sql/sql_parse.cc:
mysql_alter_table() function no longer takes handle_duplicates argument.
sql/sql_table.cc:
Got rid of handle_duplicates argument in mysql_alter_table() and
copy_data_between_tables() functions. These functions were always
called with handle_duplicates == DUP_ERROR and thus contained dead
(and probably incorrect) code.
sql/sql_trigger.cc:
Added Table_triggers_list::mark_fields_used() method which is used to mark
fields read/set by triggers as such so handlers will be able properly
retrieve/store values in these fields.
sql/sql_trigger.h:
Table_triggers_list:
Added mark_fields_used() method which is used to mark fields read/set by
triggers as such so handlers will be able properly retrieve/store values
in these fields. To implement this method added 'trigger_fields' member
which is array of lists linking items for all fields used in triggers
grouped by event and action time.
sql/sql_update.cc:
Mark fields which are used by ON UPDATE triggers so handler will retrieve
and save values for these fields.
mysql-test/r/ndb_trigger.result:
Added test for bug#18437 "Wrong values inserted with a before update trigger
on NDB table".
mysql-test/t/ndb_trigger.test:
Added test for bug#18437 "Wrong values inserted with a before update trigger
on NDB table".
into mysql.com:/opt/local/work/mysql-5.0-runtime
mysql-test/r/func_sapdb.result:
Auto merged
mysql-test/r/func_time.result:
Auto merged
mysql-test/t/func_sapdb.test:
Auto merged
mysql-test/t/func_time.test:
Auto merged
sql/item.h:
Auto merged
sql/item_timefunc.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
1.2525 06/06/30 18:29:27 monty@mysql.com +3 -0
Reverted wrong bug fix (Bug#11228)
mysql-test/r/key.result:
Manual transfer of the following fix into the 5.0.23 release clone:
1.27 06/06/30 18:29:25 monty@mysql.com +9 -1
Fixed result after removing wrong bug fix
mysql-test/t/key.test:
Manual transfer of the following fix into the 5.0.23 release clone:
1.24 06/06/30 18:29:25 monty@mysql.com +1 -0
Added SHOW CREATE TABLE, which is the proper way to check for table definitions
sql/table.cc:
Manual transfer of the following fix into the 5.0.23 release clone:
1.135 06/06/30 18:29:25 monty@mysql.com +21 -0
Reverted wrong bug fix. ...
