mysql-test/r/csv.result:
update result file
mysql-test/t/csv.test:
add a test for the bug
sql/examples/ha_tina.cc:
move open() call before my_hash_insert, so that we don't insert invalid
share to the hash. To avoid other possible problems also add
hash_delete(), so that the share is removed from hash before it is freed.
The UNCOMPRESS() function was not marked as maybe_null, even though
it returns NULL on invalid data. This confused the optimizer.
mysql-test/r/func_compress.result:
Add new results
mysql-test/t/func_compress.test:
Add new regression test
sql/item_strfunc.h:
Set maybe_null within Item_func_uncompress::fix_length_and_dec()
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.
Wrong criteria was used to distinguish the case when there was no
lookahead performed in the parser. Bug affected only statements
ending in one-character token without any optional tail, like CREATE
INDEX and CALL.
mysql-test/r/sp-code.result:
Add result for bug#19207: Final parenthesis omitted for CREATE INDEX
in Stored Procedure
mysql-test/t/sp-code.test:
Add test case for bug#19207: Final parenthesis omitted for CREATE INDEX
in Stored Procedure
sql/sql_yacc.yy:
Use (yychar == YYEMPTY) as the criteria of whether lookahead was not
performed.
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.
we didn't have code creating GEOMETRY-type fields from Items (expression results)
So i added this code
mysql-test/r/gis.result:
test result fixed
mysql-test/t/gis.test:
testcase added
sql/item_geofunc.cc:
Item_geometry_func::tmp_table_field implemented
sql/item_geofunc.h:
tmp_table_field() and get_geometry_type() declared
running)
I decided to make ps_1general test independent from actual number of
threads running
mysql-test/r/ps_1general.result:
result fixed
mysql-test/t/ps_1general.test:
as i think we don't really care about the number of threads running
i just replace the number with '#'
