- 16 Jul, 2006 1 commit
-
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/mysql-5.0-opt
-
- 15 Jul, 2006 3 commits
-
-
evgen@moonbone.local authored
Fixed bug#10977: No warning issued if a column name is truncated New warning message is added.
-
evgen@moonbone.local authored
When an alias is set to a column leading spaces are removed from the alias. But when this is done on aliases set by user this can lead to confusion. Now Item::set_name() method issues the warning if leading spaces were removed from an alias set by user. New warning message is added.
-
igor@rurik.mysql.com authored
The bug caused a crash of the server if a subquery with ORDER BY DESC used the range access method. The bug happened because the method QUICK_SELECT_DESC::reset was not reworked after MRR interface had been introduced.
-
- 14 Jul, 2006 5 commits
-
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/mysql-5.0-opt
-
gkodinov/kgeorge@macbook.gmz authored
Discussed with Kent.
-
gkodinov/kgeorge@macbook.gmz authored
into macbook.gmz:/Users/kgeorge/mysql/work/B17212-5.0-opt
-
igor@olga.mysql.com authored
-
igor@olga.mysql.com authored
DESCRIBE returned the type BIGINT for a column of a view if the column was specified by an expression over values of the type INT. E.g. for the view defined as follows: CREATE VIEW v1 SELECT COALESCE(f1,f2) FROM t1 DESCRIBE returned type BIGINT for the only column of the view if f1,f2 are columns of the INT type. At the same time DESCRIBE returned type INT for the only column of the table defined by the statement: CREATE TABLE t2 SELECT COALESCE(f1,f2) FROM t1. This inconsistency was removed by the patch. Now the code chooses between INT/BIGINT depending on the precision of the aggregated column type. Thus both DESCRIBE commands above returns type INT for v1 and t2.
-
- 13 Jul, 2006 3 commits
-
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-5.0-opt-mysql
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-5.0-opt-mysql
-
evgen@moonbone.local authored
into moonbone.local:/home/evgen/bk-trees/mysql-5.0-opt
-
- 12 Jul, 2006 4 commits
-
-
kostja@bodhi.local authored
-
mkindahl@dl145k.mysql.com authored
into dl145k.mysql.com:/data0/mkindahl/bk/mysql-5.0-rpl
-
gkodinov/kgeorge@macbook.gmz authored
* don't use join cache when the incoming data set is already ordered for ORDER BY This choice must be made because join cache will effectively reverse the join order and the results will be sorted by the index of the table that uses join cache.
-
evgen@moonbone.local authored
into moonbone.local:/work/16302-bug-4.1-opt-mysql
-
- 11 Jul, 2006 10 commits
-
-
evgen@moonbone.local authored
into moonbone.local:/work/18503-bug-4.1-mysql
-
evgen@moonbone.local authored
may return a wrong result. An Item_sum_hybrid object has the was_values flag which indicates whether any values were added to the sum function. By default it is set to true and reset to false on any no_rows_in_result() call. This method is called only in return_zero_rows() function. An ALL/ANY subquery can be optimized by MIN/MAX optimization. The was_values flag is used to indicate whether the subquery has returned at least one row. This bug occurs because return_zero_rows() is called only when we know that the select will return zero rows before starting any scans but often such information is not known. In the reported case the return_zero_rows() function is not called and the was_values flag is not reset to false and yet the subquery return no rows Item_func_not_all and Item_func_nop_all functions return a wrong comparison result. The end_send_group() function now calls no_rows_in_result() for each item in the fields_list if there is no rows were found for the (sub)query.
-
evgen@moonbone.local authored
into moonbone.local:/work/16302-bug-4.1-opt-mysql
-
evgen@moonbone.local authored
into moonbone.local:/home/evgen/bk-trees/mysql-4.1-opt
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime-merge-41
-
ingo/mydev@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-amerge
-
joerg@trift2. authored
-
joerg@trift2. authored
into trift2.:/M50/mysql-5.0
-
mkindahl@dl145k.mysql.com authored
into dl145k.mysql.com:/data0/mkindahl/bk/MERGE/mysql-5.0-merge
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime-merge-41
-
- 10 Jul, 2006 14 commits
-
-
kostja@bodhi.local authored
-
joerg@trift2. authored
into trift2.:/M50/mysql-5.0
-
joerg@trift2. authored
-
evgen@moonbone.local authored
into moonbone.local:/work/allany-4.1-mysql
-
evgen@moonbone.local authored
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.
-
kostja@bodhi.local authored
-
ingo/mydev@chilla.local authored
-
guilhem@gbichot3.local authored
into gbichot3.local:/home/mysql_src/mysql-5.0
-
gkodinov/kgeorge@macbook.gmz authored
-
gkodinov/kgeorge@macbook.gmz authored
into macbook.gmz:/Users/kgeorge/mysql/work/B14553-5.0-opt
-
gkodinov/kgeorge@macbook.gmz authored
into macbook.gmz:/Users/kgeorge/mysql/work/B14553-4.1-opt
-
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.
-
kostja@bodhi.local authored
-
pekka@orca.ndb.mysql.com authored
into orca.ndb.mysql.com:/space_old/pekka/ndb/version/my50-1.2167.1.2
-