1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-11 15:22:09 +03:00
Commit Graph

20681 Commits

Author SHA1 Message Date
03bf73de2f Merge from mysql-5.1. 2009-10-19 17:28:31 +04:00
ead175bb07 Bug#45645 Mysql server close all connection and restart using lower function
Problem: the "caseinfo" member of CHARSET_INFO structure was not
initialized for user-defined Unicode collations, which made the
server crash.
Fix: initializing caseinfo properly.
2009-10-19 18:23:53 +05:00
3251065aef Merge from mysql-5.1. 2009-10-19 17:17:08 +04:00
3088f6c7ba Back-port from 6.0 of the fix for
BUG#38049 "incorrect rows estimations with references from preceding table"
(from revid:sergefp@mysql.com-20090126194259-ue20il3qro529l4d).
Compared to 6.0 where EXPLAIN indicates "Using index condition", here in join_optimizer.result
we see "Using where"; it's normal; 6.0 shows the same if disabling Index Condition Pushdown.
2009-10-19 15:14:43 +02:00
425c5ecd7c Bug#34374 mysql generates incorrect warning
backport to next-mr
2009-10-19 15:13:45 +02:00
d1b03b432f Automerge 2009-10-19 15:00:38 +02:00
0659b857e7 Bug#27145 EXTRA_ACL troubles
The flag EXTRA_ACL is used in conjugation with our access checks, yet it is
not clear what impact this flag has.
This is a code clean up which replaces use of EXTRA_ACL with an explicit
function parameter.
The patch also fixes privilege checks for:
- SHOW CREATE TABLE: The new privilege requirement is any privilege on
  the table-level.
- CHECKSUM TABLE: Requires SELECT on the table level.
- SHOW CREATE VIEW: Requires SHOW_VIEW and SELECT on the table level
  (just as the manual claims)
- SHOW INDEX: Requires any privilege on any column combination.


mysql-test/r/grant.result:
  * Error message now shows correct command (SHOW instead of SELECT)
mysql-test/r/grant2.result:
  * Error message now shows correct command (SHOW instead of SELECT)
mysql-test/r/grant4.result:
  * This test file tests privilege requirements for
    SHOW COLUMNS
    CREATE TABLE .. LIKE
    SHOW CREATE TABLE
    SHOW INDEX
    CHECKSUM TABLE
    SHOW CREATE VIEW
mysql-test/r/information_schema_db.result:
  * Added SELECT privilege to testdb_2 as
    SHOW CREATE VIEW now demands this privilege
    as well as SHOW VIEW.
mysql-test/r/outfile.result:
  * Changed error code
mysql-test/r/view_grant.result:
  * Additional SELECT privilege is now needed
    for SHOW CREATE VIEW
mysql-test/t/grant4.test:
  * This test file tests privilege requirements for
    SHOW COLUMNS
    CREATE TABLE .. LIKE
    SHOW CREATE TABLE
    SHOW INDEX
    CHECKSUM TABLE
    SHOW CREATE VIEW
mysql-test/t/information_schema_db.test:
  * Added SELECT privilege to testdb_2 as
    SHOW CREATE VIEW now demands this privilege
    as well as SHOW VIEW.
mysql-test/t/outfile.test:
  * Changed error code
mysql-test/t/view_grant.test:
  * Additional SELECT privilege is now needed
    for SHOW CREATE VIEW
sql/mysql_priv.h:
  * Replaced EXTRA_ACL with a parameter
sql/sp_head.cc:
  * Replaced EXTRA_ACL with a parameter
sql/sql_acl.cc:
  * Converted function documentation to doxygen and clarified some behaviors.
  * Changed value from uint to bool to better reflect its meaning.
  * Removed pointless variable orig_want_access
  * Added function has_any_table_level_privileges to help with requirements
    checks during SHOW CREATE TABLE.
sql/sql_acl.h:
  * changed signature of check_grant()
  * introduced access control function has_any_table_leevl_privileges()
sql/sql_base.cc:
  * Check_table_access has new signature
sql/sql_cache.cc:
  * Check_table_access has new signature
sql/sql_parse.cc:
  * Rewrote function documentation in doxygen comments for: check_access,
    check_table_acces, check_grant.
  * Removed EXTRA_ACL flag where it doesn't hold any meaningful purpose anymore
    and replaced it with a function parameter where any privileges on any column
    combination would satisfy the requirement.
  * Fixed privilege check for SHOW COLUMNS and SHOW INDEX
  * Modified check_table_access to gain clarity in what EXTRA_ACL actually does.
  * Modified check_access to gain clarity in what EXTRA_ACL actually does.
  * Fixed privilege check for CREATE TABLE .. LIKE .. ; It now requires SELECT
    privileges on the table.
  * Fixed privilege check for SHOW CREATE TABLE ..; It now requires any privilege
    on the table level.
sql/sql_plugin.cc:
  * check_table_access has new signature
sql/sql_prepare.cc:
  * check_table_access has new signature
sql/sql_show.cc:
  * check_table_access has new signature
sql/sql_trigger.cc:
  * check_table_access has new signature
sql/sql_update.cc:
  * check grant has new signature
sql/sql_view.cc:
  * check_table_access has new signature
2009-10-19 14:58:13 +02:00
ec7c4fb442 port of fixes for bug-20577 and 46362 for TO_SECONDS 2009-10-19 13:40:08 +02:00
60fc8507bd Bug#30302: Tables that were optimized away are printed in the
EXPLAIN EXTENDED warning.

Query optimizer searches for the constant tables and optimizes them away. This
means that fields of such tables are substituted for their values and on later
phases they are treated as constants. After this constant tables are removed
from the query execution plan. Nevertheless constant tables were shown in 
the EXPLAIN EXTENDED warning thus producing query that might be not an
equivalent of the original query.
        
Now the print_join function skips all tables that were optimized away from
printing to the EXPLAIN EXTENDED warning. If all tables were optimized away it
produces the 'FROM dual' clause.


mysql-test/r/explain.result:
  A test case added for the bug#30302.
mysql-test/r/func_default.result:
  Adjusted test case result after fix for the bug#30302.
mysql-test/r/func_regexp.result:
  Adjusted test case result after fix for the bug#30302.
mysql-test/r/func_test.result:
  Adjusted test case result after fix for the bug#30302.
mysql-test/r/having.result:
  Adjusted test case result after fix for the bug#30302.
mysql-test/r/select.result:
  Adjusted test case result after fix for the bug#30302.
mysql-test/r/subselect.result:
  Adjusted test case result after fix for the bug#30302.
mysql-test/r/subselect3.result:
  Adjusted test case result after fix for the bug#30302.
mysql-test/r/type_datetime.result:
  Adjusted test case result after fix for the bug#30302.
mysql-test/t/explain.test:
  A test case added for the bug#30302.
sql/sql_select.cc:
  Bug#30302: Tables that were optimized away are printed in the
  EXPLAIN EXTENDED warning.
  Now the print_join function skips all tables that were optimized away from
  printing to the EXPLAIN EXTENDED warning. If all tables were optimized away it
  produces the 'FROM dual' clause.
sql/table.h:
  Adjusted test case result after fix for the bug#30302.
  The optimized_away flag is added to the TABLE_LIST struct.
2009-10-19 15:13:26 +04:00
93e02adcfa Manual merge mysql-trunk -> mysql-trunk-wl3352 2009-10-19 12:09:52 +02:00
14fe0fa509 Bug#43207 wrong LC_TIME names for romanian locale
Adding tests for the bug.
2009-10-19 13:44:44 +05:00
d850a57c3b Bug#46633 Obsolete Serbian locale name
- Renaming sr_YU to sr_RS
- Adding test case
2009-10-19 12:52:29 +05:00
834ba32293 Bug#47627 SET @@{global.session}.local_variable in stored routine causes crash
Adding @@session and @@global prefixes to a
declared variable in a stored procedure the server
would lead to a crash.

The reason was that during the parsing of the
syntactic rule 'option_value' an uninitialized
set_var object was pushed to the parameter stack
of the SET statement. The parent rule
'option_type_value'  interpreted the existence of
variables on the parameter stack as an assignment
and wrapped it in a sp_instr_set object.

As the procedure later was executed an attempt
was made to run the method 'check()' on an
uninitialized member object (NULL value) belonging
to the previously created but uninitialized object.


sql/sql_yacc.yy:
  * Assign the option_type at once since it is needed by the next
    parsing rule (internal_variable_name)
  * Rearranged the if statement to reduce negations and gain more
    clarity of code.
  * Added check for option_type to better detect if current
    variable is a SP local variable or a system variable.
2009-10-19 09:43:33 +02:00
0b43c4e74c Fix for bug#47963: Wrong results when index is used
Problem: using null microsecond part in a WHERE condition 
(e.g. WHERE date_time_field <= "YYYY-MM-DD HH:MM:SS.0000") 
may lead to wrong results due to improper DATETIMEs 
comparison in some cases.

Fix: comparing DATETIMEs as strings we must trim trailing 0's
in such cases.


mysql-test/r/innodb_mysql.result:
  Fix for bug#47963: Wrong results when index is used
    - test result.
mysql-test/t/innodb_mysql.test:
  Fix for bug#47963: Wrong results when index is used
    - test case.
sql/item.cc:
  Fix for bug#47963: Wrong results when index is used
    - comparing DATETIMEs as strings we must trim trailing 0's in the 
  microsecond part to ensure
  'YYYY-MM-DD HH:MM:SS.000' == 'YYYY-MM-DD HH:MM:SS'
2009-10-18 21:26:55 +05:00
cf7afa1164 merge from next-mr 2009-10-18 10:08:07 +02:00
bc1f79fb3e merge from trunk 2009-10-18 09:54:50 +02:00
9630512875 Manual merge 5.1-rep+2 to 5.1-rep+3 2009-10-18 11:57:38 +08:00
72c96cbd0e merge from 5.1 main 2009-10-16 23:25:05 +02:00
f6868a4eb4 Bug #47123: Endless 100% CPU loop with STRAIGHT_JOIN
The problem was in incorrect handling of predicates involving 
NULL as a constant value by the range optimizer. 
 
For example, when creating a SEL_ARG node from a condition of 
the form "field < const" (which would normally result in the 
"NULL < field < const" SEL_ARG),  the special case when "const" 
is NULL was not taken into account, so "NULL < field < NULL" 
was produced for the "field < NULL" condition. 
 
As a result, SEL_ARG structures of this form could not be 
further optimized which in turn could lead to incorrectly 
constructed SEL_ARG trees. In particular, code assuming SEL_ARG 
structures to always form a sequence of ordered disjoint 
intervals could enter an infinite loop under some 
circumstances. 
 
Fixed by changing get_mm_leaf() so that for any sargable 
predicate except "<=>" involving NULL as a constant, "empty" 
SEL_ARG is returned, since such a predicate is always false. 

mysql-test/r/partition_pruning.result:
  Fixed a broken test case.
mysql-test/r/range.result:
  Added a test case for bug #47123.
mysql-test/r/subselect.result:
  Fixed a broken test cases.
mysql-test/t/range.test:
  Added a test case for bug #47123.
sql/opt_range.cc:
  Fixed get_mm_leaf() so that for any sargable
  predicate except "<=>" involving NULL as a constant, "empty"
  SEL_ARG is returned, since such a predicate is always false.
2009-10-17 00:19:51 +04:00
b7c3a76cfe Pull from mysql-next-mr-runtime. 2009-10-16 20:30:20 +04:00
760dd08d97 Merged in latest changes 2009-10-16 17:44:49 +02:00
29b7a0aadc Removed GLOBAL INDEX syntax, need to develop GLOBAL indexes before adding syntax for it 2009-10-16 17:41:15 +02:00
c90669c4d4 Fixed removal of column_list keyword for VALUES part, retained for PARTITION BY RANGE/LIST COLUMN_LIST, not entirely working yet 2009-10-16 16:16:06 +02:00
3138ee3be1 Backport of 2617.65.4 from 6.0-codebase.
A fix and a test case for Bug#34898 "mysql_info() reports 0 warnings
while mysql_warning_count() reports 1"

Review the patch by Chad Miller, implement review comments
(since Chad left) and push the patch.

This bug is actually not a bug. At least according to Monty.
See Bug#841 "wrong number of warnings" reported back in July 2003
and closed as "not a bug".
mysql_info() was printing the number of truncated columns, not
the number of warnings.
But since the message of mysql_info() was "Warnings: <number of truncated
columns>", people would expect to get the number
of warnings in it, not the number of truncated columns.

So a possible fix would be to change the message of mysql_info()
to say Rows changed: <n>, truncated: <m>.

Instead, put the number of warnings there. That is, remove the
feature that thd->cuted_fields (the number of truncated fields)
is exposed to the client. The number of truncated columns can be
calculated on the client, by analyzing SHOW WARNINGS output,
and in future we may remove thd->cuted_fields altogether.
So let's have one less thing to worry about.

client/mysqltest.cc:
  Fix a bug in mysqltest program which used to return
  a wrong number of affected rows in ps-protocol, and a wrong
  mysql_info() information in both protocols in presence of warnings.
mysql-test/r/insert.result:
  Update results (Bug#34898)
mysql-test/suite/rpl/r/rpl_udf.result:
  Update to the changed output of mysqltest: mysql_info() is now printed
  before warnings.
mysql-test/t/insert.test:
  Add a test case for Bug#34898.
sql/sql_table.cc:
  A fix for Bug#34898 - report statement warn count, not the
  number of truncated values in mysql_info().
sql/sql_update.cc:
  A fix for Bug#34898 - report statement warn count, not the
  number of truncated values in mysql_info().
2009-10-16 17:41:43 +04:00
d63eb541f5 Merging Innodb plugin 1.0.5 revisions from 5.1-main from revisions 3149 to 3163
also merged missing Innodb plugin revisions r5636,r5635 manually
2009-10-16 17:28:02 +05:30
3bd2461668 Bug#46019: ERROR 1356 When selecting from within another
view that has Group By
      
When SELECT'ing from a view that mentions another,
materialized, view, access was being denied. The issue was
resolved by lifting a special case which avoided such access
checking in check_single_table_access. In the past, this was
necessary since if such a check were performed, the error
message would be downgraded to a warning in the case of SHOW
CREATE VIEW. The downgrading of errors was meant to handle
only that scenario, but could not distinguish the two as it
read only the error messages.
      
The special case was needed in the fix of bug no 36086.
Before that, views were confused with derived tables.
      
After bug no 35996 was fixed, the manipulation of errors
during SHOW CREATE VIEW execution is not dependent on the
actual error messages in the queue, it rather looks at the
actual cause of the error and takes appropriate
action. Hence the aforementioned special case is now
superfluous and the bug is fixed.


mysql-test/r/view_grant.result:
  Bug#46019: Test result.
mysql-test/t/view_grant.test:
  Bug#46019: Test case.
sql/sql_parse.cc:
  Bug#46019: fix.
2009-10-16 13:12:21 +02:00
d80e35f26f Revert the fix for bug #47123 until test suite failures are resolved. 2009-10-16 11:42:16 +03:00
7175733938 A backporting patch for the following revision from 6.0:
revno: 2630.22.41
committer: Alexander Nozdrin <alik@mysql.com>
branch nick: 6.0-rt-bug39255
timestamp: Thu 2008-10-16 16:39:30 +0400
message:
  A patch for Bug#39255: Stored procedures: crash if function
  references nonexistent table.
  
  The problem is not reproduced in 6.0. Adding a test case.
2009-10-15 21:08:41 +04:00
a363c06ed0 Bug #43054 Assertion `!table->auto_increment_field_not_null' failed when
redefining trigger
      
The 'table->auto_increment_field_not_null' flag is only valid within
processing of a single row, and should be set to FALSE before
navigating to the next row, or exiting the operation.
      
This bug was caused by an SQL error occuring while executing a trigger
after the flag had been set, so the normal resetting was bypassed.
The table object was then returned to the table share's cache in
a dirty condition.   When the table object was reused, an assert
caught that the flag was set.
      
This patch explicitly clears the flag on error/abort.


Backported from mysql-6.0-codebase  revid: 2617.52.1
2009-10-15 14:53:06 +02:00
d8c3f2263f WL#751 Error message construction, backport 2009-10-15 17:23:43 +05:00
79406bc49a Manual merge. 2009-10-15 14:42:51 +04:00
3929dddcd7 Backporting WL#4164 Two-byte collation IDs 2009-10-15 15:17:32 +05:00
ffbe8512f8 Bug #38124 "general_log_file" variable silently unset when using expression
When assigning the new string value to the variable, the
Item::str_value member was used.  This is not according to
the protocol.  str_value is an internal member used for
temporary assignments, and is not consistently set for all
string operations.  It is set for constant strings, so it would
work in these cases, but not for string functions (concat,
substr, etc.)
                  
The correct approach is to use Item::val_str(..) to evaluate
and retrieve the string.

Backport from 6.0-codebase

6.0-codebase revno: 2617.31.17
2009-10-15 11:09:31 +02:00
eade898061 Disabled part of test for BUG#47073 until additional fix is pushed. 2009-10-15 12:31:11 +05:00
3dce051cc5 Backport of revno: 2617.81.4
Bug #47274 assert in open_table on CREATE TABLE <already existing>

The problem was an assertion during execution of CREATE TABLES. 
This assertion would occur if INSERT DELAYED or REPLACE DELAYED
were used to update a table containing an AUTO_INCREMENT column
and if the inserted row had a user-supplied value for that column.
Any CREATE TABLE statement (including CREATE TABLE SELECT and
CREATE TABLE LIKE) trying to create the same table and 
which followed the INSERT/REPLACED would cause the assertion.

The problem was only noticeable on debug builds of the server
and not present in the mysql-5.1 tree.

The cause of the problem was that the code for delayed insert did
not properly reset the TABLE->auto_increment_if_null flag after 
The flag is used to indicate that a non-null value of an auto_increment field
has been provided by the user or retrieved from a current record.
Open_tables() contains an assertion that tests this flag, and this
was triggered by CREATE TABLE.

This patch fixes the problem by resetting the auto_increment_if_null
field to FALSE once INSERT/REPLACE DELAYED has updated the table, 
similar to what is done already for regular INSERT statements.

Test case added to delayed.test.
2009-10-14 14:50:26 +02:00
4def52165d A postfix for backporting WL#1397 convert XML -> SQL
mysql-test/r/loadxml.result
mysql-test/t/loadxml.test
  Fixing non-deterministic test results

sql/sql_yacc.yy
  Initializing fname_first using get_tok_end() instead of get_ptr().
  The latter is grammar-dependant. The former is not.
2009-10-14 17:10:22 +05:00
8e65618fa9 BUG#47455 - The myisam_crash_before_flush_keys test fails on Windows
Simplified and made more determenistic myisam_crash_before_flush_keys
test.

mysql-test/r/myisam_crash_before_flush_keys.result:
  We don't need myisamchk to test this bug fix. CHECK TABLE
  after server restart is enough to ensure that the fix
  works.
mysql-test/t/myisam_crash_before_flush_keys.test:
  We don't need myisamchk to test this bug fix. CHECK TABLE
  after server restart is enough to ensure that the fix
  works.
2009-10-14 16:26:16 +05:00
6da93b223b Bug#47280 - strange results from count(*) with order by multiple
columns without where/group
                     
Simple SELECT with implicit grouping used to return many rows if
the query was ordered by the aggregated column in the SELECT
list. This was incorrect because queries with implicit grouping
should only return a single record.
                              
The problem was that when JOIN:exec() decided if execution needed
to handle grouping, it was assumed that sum_func_count==0 meant
that there were no aggregate functions in the query. This
assumption was not correct in JOIN::exec() because the aggregate
functions might have been optimized away during JOIN::optimize().
                  
The reason why queries without ordering behaved correctly was
that sum_func_count is only recalculated if the optimizer chooses
to use temporary tables (which it does in the ordered case).
Hence, non-ordered queries were correctly treated as grouped.
                  
The fix for this bug was to remove the assumption that
sum_func_count==0 means that there is no need for grouping. This
was done by introducing variable "bool implicit_grouping" in the
JOIN object.

mysql-test/r/func_group.result:
  Add test for BUG#47280
mysql-test/t/func_group.test:
  Add test for BUG#47280
sql/opt_sum.cc:
  Improve comment for opt_sum_query()
sql/sql_class.h:
  Add comment for variables in TMP_TABLE_PARAM
sql/sql_select.cc:
  Introduce and use variable implicit_grouping instead of (!group_list && sum_func_count) in places that need to test if grouping is required. Also added comments for: optimization of aggregate fields for implicitly grouped queries  (JOIN::optimize) and choice of end_select method (JOIN::execute)
sql/sql_select.h:
  Add variable implicit_grouping, which will be TRUE for queries that contain aggregate functions but no GROUP BY clause. Also added comment to sort_and_group variable.
2009-10-14 10:46:50 +02:00
c30d924dd5 Manual merge from mysql-trunk-merge. 2009-10-14 12:25:39 +04:00
edebd2a223 Backport of:
-----------------------------------------------------------
revno: 2630.2.4
committer: Konstantin Osipov <konstantin@mysql.com>
branch nick: mysql-6.0-runtime
timestamp: Fri 2008-05-23 02:42:32 +0400
message:
  Bug#27430 "Crash in subquery code when in PS and table DDL changed after
  PREPARE"
  Add a test case for the situation with small TDC and many merge children.

from 6.0-codebase.

mysql-test/r/merge.result:
  Update results (Bug#27430)
mysql-test/t/merge.test:
  Add test case (Bug#27430)
2009-10-13 23:04:58 +04:00
1360ca0962 Backport of fix to bug #33629 into mysql-next-mr-bugfixing.
Bug #33629: last_day function can return null, but has 'not null' flag set for result

LAST_DAY and MAKEDATE functions are documented as
returning NULL value, but actually they was implemented
as returning NOT NULL typed values.

That caused a confusing error "ERROR 1048 (23000): Column
'...' cannot be null" on queries like: 

  SELECT 1 FROM (SELECT LAST_DAY('0')) a;


mysql-test/r/func_sapdb.result:
    Updated test case for bug #33629.
mysql-test/r/func_time.result:
    Updated test case for bug #33629.
mysql-test/r/type_date.result:
    Added test case for bug #33629.
mysql-test/t/type_date.test:
    Added test case for bug #33629.
sql/item_timefunc.h:
    Bug #33629: last_day function can return null, but has 'not null' flag set for result
    
    1. The Item_func_makedate::fix_length_and_dec method
       has been modified to declare MAKEDATE() as a function
       returning nullable value.
    2. The Item_func_last_day::fix_length_and_dec method
       has been overloaded for the same purpose.
2009-10-13 21:50:08 +05:00
bc9f56a6c2 Bug #47123: Endless 100% CPU loop with STRAIGHT_JOIN
The problem was in incorrect handling of predicates involving 
NULL as a constant value by the range optimizer.  
 
For example, when creating a SEL_ARG node from a condition of 
the form "field < const" (which would normally result in the 
"NULL < field < const" SEL_ARG),  the special case when "const" 
is NULL was not taken into account, so "NULL < field < NULL" 
was produced for the "field < NULL" condition. 
 
As a result, SEL_ARG structures of this form could not be 
further optimized which in turn could lead to incorrectly 
constructed SEL_ARG trees. In particular, code assuming SEL_ARG 
structures to always form a sequence of ordered disjoint 
intervals could enter an infinite loop under some 
circumstances. 
 
Fixed by changing get_mm_leaf() so that for any sargable 
predicate except "<=>" involving NULL as a constant, "empty" 
SEL_ARG is returned, since such a predicate is always false. 

mysql-test/r/range.result:
  Added a test case for bug #47123.
mysql-test/t/range.test:
  Added a test case for bug #47123.
sql/opt_range.cc:
  Fixed get_mm_leaf() so that for any sargable 
  predicate except "<=>" involving NULL as a constant, "empty" 
  SEL_ARG is returned, since such a predicate is always false.
2009-10-13 19:49:32 +04:00
c69629d269 Merge from mysql-5.1. 2009-10-13 13:42:38 +04:00
7e3b4d21c0 Backport of the patch for bug #8457 "Precision math: DIV
returns incorrect result with large decimal value" 
 
For the DIV operator, neither operands nor result were checked 
for integer overflows. 
 
This patch changes the DIV behavior for non-integer operands as 
follows: if either of the operands has a non-integer type, 
convert both operands to the DECIMAL type, then calculate the 
division using DECIMAL arithmetics. Convert the resulting 
DECIMAL value into BIGINT [UNSIGNED] if it fits into the 
corresponding range, or throw an 'out of range' error 
otherwise. 

mysql-test/r/func_math.result:
  Added a test case for bug #8457.
  Fixed results for a test case depending on the wrong behavior.
mysql-test/r/type_varchar.result:
  Fixed results for a test case depending on the wrong behavior.
mysql-test/t/func_math.test:
  Added a test case for bug #8457.
sql/item_func.cc:
  If either of the operands has a non-integer type, convert both 
  operands to the DECIMAL type, then calculate the division using 
  DECIMAL arithmetics. Convert the resulting DECIMAL value into 
  BIGINT [UNSIGNED] if it fits into the corresponding range, or 
  throw an 'out of range' error otherwise.
2009-10-13 12:31:42 +04:00
610213149c merge to mysql-5.1-bugteam 2009-10-13 12:48:29 +05:30
662d836744 Fix for bug#47963: Wrong results when index is used
Problem: using null microsecond part (e.g. "YYYY-MM-DD HH:MM:SS.0000") 
in a WHERE condition may lead to wrong results due to improper
DATETIMEs comparison in some cases.

Fix: as we compare DATETIMEs as strings we must trim trailing 0's
in such cases.


mysql-test/r/innodb_mysql.result:
  Fix for bug#47963: Wrong results when index is used
    - test result.
mysql-test/t/innodb_mysql.test:
  Fix for bug#47963: Wrong results when index is used
    - test case.
sql/item.cc:
  Fix for bug#47963: Wrong results when index is used
    - comparing DATETIMEs trim trailing 0's in the 
  microsecond part.
2009-10-13 09:43:27 +05:00
9a65687bd9 Bug #33693 general log name and location depend on PID file,
not on predefined values

The default name of the PID file was constructed, as documented, 
based on the hostname.  This name was subsequently used as the
base for the general log file name.   If the name of the PID
file was overridden in the configuration, and no explicit name
was set for the general log file, the path location for the
PID file was used also for the general log file.
                  
A new variable, 'default_logfile_name', has been introduced.  This name
is constructed based on the hostname, and is then used to
construct both the PID file and the general log file.
                  
The general log file will now, unless explicitly set, be
located in the server data directory (as documentated in
the server docs)


mysql-test/t/log_state.test:
  run/mysqld.log was created as a consequence of this bug.
  After the fix it is no longer created, and will thus not
  be deleted.
2009-10-12 15:35:30 +02:00
16537b0336 Bug #35877 Update .. WHERE with function, constraint violation, crash
Unable to reproduce crash with current version of the 5.5.0 codebase.
Test case for MyISAM/InnoDB based on the bug rapport added to 
sp_trans.test.

Backport of revno: 2617.65.9.
2009-10-12 13:41:02 +02:00
1186f5ec18 Bug #34453 Can't change size of file (Errcode: 1224)
Unable to reproduce error on current version of the 5.5.0
codebase. Test case based on the bug report added to trigger.test.

Backport of revno: 2617.52.11.
2009-10-12 12:59:55 +02:00
64e89a7ed2 Bug#46448 trailing spaces are not ignored when user collation maps space != 0x20
In MySQL when the mapping for space is changed to something other than
0x20 by defining a different collation, then space is not ignored when
comparing two strings.

This was happening because the function that performs the comparison
of two strings while ignoring ending spaces, was comparing the collation
value of a space with the ascii value of the ' ' character. This should
be changed to do comparison between the collated values.

mysql-test/r/ctype_ldml.result:
  Bug#46448 trailing spaces are not ignored when user collation maps space != 0x20
  
  Result file for test case.
mysql-test/std_data/Index.xml:
  Bug#46448 trailing spaces are not ignored when user collation maps space != 0x20
  
  Added entry for new test collation in the index file.
mysql-test/std_data/latin1.xml:
  Bug#46448 trailing spaces are not ignored when user collation maps space != 0x20
  
  Added support for new collation for test.
mysql-test/t/ctype_ldml.test:
  Bug#46448 trailing spaces are not ignored when user collation maps space != 0x20
  
  Added test case to ensure trailing spaces are not ignored.
strings/ctype-simple.c:
  Bug#46448 trailing spaces are not ignored when user collation maps space != 0x20
  
  change my_strnncollsp_simple to compare collated values when checking
  for trailing spaces. Currently the comparison happens between a collated
  value and the ascii value.
2009-10-12 13:13:15 +05:30