GitLab

Problem:-
using last_insert_id() on an auto_incremented bigint unsigned does
not work for values which are greater than max-bigint-signed.

Analysis:-
last_insert_id() returns the first auto_incremented value for a column
and an auto_incremented value can have only positive values.

In our code, when we are initializing a last_insert_id object, we are
taking it as a signed BIGINT, So when the auto_incremented value reaches
greater than max signed bigint, last_insert_id gives negative result.

Solution:
When we are fetching the value from last_insert_id, We are setting the 
unsigned_flag, so that it take only unsigned BIGINT value.

Assertion happens due to missing NULL value check in
Item_func_round::fix_length_and_dec() function.
The fix: added NULL value check for second parameter.

In sql_class.cc, 'row_count', of type 'ha_rows', was used as last argument for
ER_TRUNCATED_WRONG_VALUE_FOR_FIELD which is
"Incorrect %-.32s value: '%-.128s' for column '%.192s' at row %ld".
So 'ha_rows' was used as 'long'.
On SPARC32 Solaris builds, 'long' is 4 bytes and 'ha_rows' is 'longlong' i.e. 8 bytes.
So the printf-like code was reading only the first 4 bytes.
Because the CPU is big-endian, 1LL is 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01
so the first four bytes yield 0. So the warning message had "row 0" instead of
"row 1" in test outfile_loaddata.test:
-Warning	1366	Incorrect string value: '\xE1\xE2\xF7' for column 'b' at row 1
+Warning	1366	Incorrect string value: '\xE1\xE2\xF7' for column 'b' at row 0

All error-messaging functions which internally invoke some printf-life function
are potential candidate for such mistakes.
One apparently easy way to catch such mistakes is to use
ATTRIBUTE_FORMAT (from my_attribute.h).
But this works only when call site has both:
a) the format as a string literal
b) the types of arguments.
So:
  func(ER(ER_BLAH), 10);
will silently not be checked, because ER(ER_BLAH) is not known at
compile time (it is known at run-time, and depends on the chosen
language).
And
  func("%s", a va_list argument);
has the same problem, as the *real* type of arguments is not
known at this site at compile time (it's known in some caller).
Moreover,
  func(ER(ER_BLAH));
though possibly correct (if ER(ER_BLAH) has no '%' markers), will not
compile (gcc says "error: format not a string literal and no format
arguments").

Consequences:
1) ATTRIBUTE_FORMAT is here added only to functions which in practice
take "string literal" formats: "my_error_reporter" and "print_admin_msg".
2) it cannot be added to the other functions: my_error(),
push_warning_printf(), Table_check_intact::report_error(),
general_log_print().

To do a one-time check of functions listed in (2), the following
"static code analysis" has been done:
1) replace
  my_error(ER_xxx, arguments for substitution in format)
with the equivalent
  my_printf_error(ER_xxx,ER(ER_xxx), arguments for substitution in
format),
so that we have ER(ER_xxx) and the arguments *in the same call site*
2) add ATTRIBUTE_FORMAT to push_warning_printf(),
Table_check_intact::report_error(), general_log_print()
3) replace ER(xxx) with the hard-coded English text found in
errmsg.txt (like: ER(ER_UNKNOWN_ERROR) is replaced with
"Unknown error"), so that a call site has the format as string literal
4) this way, ATTRIBUTE_FORMAT can effectively do its job
5) compile, fix errors detected by ATTRIBUTE_FORMAT
6) revert steps 1-2-3.
The present patch has no compiler error when submitted again to the
static code analysis above.
It cannot catch all problems though: see Field::set_warning(), in
which a call to push_warning_printf() has a variable error
(thus, not replacable by a string literal); I checked set_warning() calls
by hand though.

See also WL 5883 for one proposal to avoid such bugs from appearing
again in the future.

The issues fixed in the patch are:
a) mismatch in types (like 'int' passed to '%ld')
b) more arguments passed than specified in the format.
This patch resolves mismatches by changing the type/number of arguments,
not by changing error messages of sql/share/errmsg.txt. The latter would be wrong,
per the following old rule: errmsg.txt must be as stable as possible; no insertions
or deletions of messages, no changes of type or number of printf-like format specifiers,
are allowed, as long as the change impacts a message already released in a GA version.
If this rule is not followed:
- Connectors, which use error message numbers, will be confused (by insertions/deletions
of messages)
- using errmsg.sys of MySQL 5.1.n with mysqld of MySQL 5.1.(n+1)
could produce wrong messages or crash; such usage can easily happen if
installing 5.1.(n+1) while /etc/my.cnf still has --language=/path/to/5.1.n/xxx;
or if copying mysqld from 5.1.(n+1) into a 5.1.n installation.
When fixing b), I have verified that the superfluous arguments were not used in the format
in the first 5.1 GA (5.1.30 'bteam@astra04-20081114162938-z8mctjp6st27uobm').
Had they been used, then passing them today, even if the message doesn't use them
anymore, would have been necessary, as explained above.

Bug#11764671  57533: UNINITIALISED VALUES IN COPY_AND_CONVERT (SQL_STRING.CC) WITH CERTAIN CHA
When ROUND evaluates decimal result it uses Item::decimal
value as fraction value for the result. In some cases
Item::decimal is greater than real result fraction value
and uninitialised memory of result(decimal) buffer can be
used in further calculations. Issue is introduced by
Bug33143 fix. The fix is to remove erroneous assignment.

Valgrind warning happens due to missing NULL value check in
Item_func::val_decimal. The fix is to add this check.

Assert fails due to overflow which happens in
Item_func_int_val::fix_num_length_and_dec() as
geometry functions have max_length value equal to
max_field_size(4294967295U). The fix is to skip
max_length calculation for some boundary cases.

Assertion happens due to missing initialization of unsigned_flag
for Item_func_set_user_var object. It leads to incorrect
calculation of decimal field size.
The fix is to add initialization of unsigned_flag.

      
Problem: wrong character set pointer was passed to my_strtoll10_mb2,
which led to DBUG_ASSERT failure in some cases.

  @ mysql-test/r/func_encrypt_ucs2.result
  @ mysql-test/t/func_encrypt_ucs2.test
  @ mysql-test/r/ctype_ucs.result
  @ mysql-test/t/ctype_ucs.test
  Adding tests

  @ sql/item_func.cc
  "cs" initialization was wrong (res does not necessarily point to &str_value)

  @ sql/item_strfunc.cc
  Item_func_dec_encrypt::val_str() and Item_func_des_descrypt::val_str()
  did not set character set for tmp_value (the returned value),
  so the old value, which was previously copied from args[1]->val_str(),
  was incorrectly returned with tmp_value.

> ------------------------------------------------------------
> revno: 3520
> revision-id: sergey.glukhov@oracle.com-20101214093303-wmo9mqcb8rz0wv9f
> parent: tor.didriksen@oracle.com-20101213161301-81lprlbune7r98dl
> committer: Sergey Glukhov <sergey.glukhov@oracle.com>
> branch nick: mysql-5.1-bugteam
> timestamp: Tue 2010-12-14 12:33:03 +0300
> message:
>   Fixed following problems:
>   --Bug#52157 various crashes and assertions with multi-table update, stored function
>   --Bug#54475 improper error handling causes cascading crashing failures in innodb/ndb
>   --Bug#57703 create view cause Assertion failed: 0, file .\item_subselect.cc, line 846
>   --Bug#57352 valgrind warnings when creating view
>   --Recently discovered problem when a nested materialized derived table is used
>     before being populated and it leads to incorrect result
>   
>   We have several modes when we should disable subquery evaluation.
>   The reasons for disabling are different. It could be
>   uselessness of the evaluation as in case of 'CREATE VIEW'
>   or 'PREPARE stmt', or we should disable subquery evaluation
>   if tables are not locked yet as it happens in bug#54475, or
>   too early evaluation of subqueries can lead to wrong result
>   as it happened in Bug#19077.
>   Main problem is that if subquery items are treated as const
>   they are evaluated in ::fix_fields(), ::fix_length_and_dec()
>   of the parental items as a lot of these methods have
>   Item::val_...() calls inside.
>   We have to make subqueries non-const to prevent unnecessary
>   subquery evaluation. At the moment we have different methods
>   for this. Here is a list of these modes:
>   
>   1. PREPARE stmt;
>   We use UNCACHEABLE_PREPARE flag.
>   It is set during parsing in sql_parse.cc, mysql_new_select() for
>   each SELECT_LEX object and cleared at the end of PREPARE in
>   sql_prepare.cc, init_stmt_after_parse(). If this flag is set
>   subquery becomes non-const and evaluation does not happen.
>   
>   2. CREATE|ALTER VIEW, SHOW CREATE VIEW, I_S tables which
>      process FRM files
>   We use LEX::view_prepare_mode field. We set it before
>   view preparation and check this flag in
>   ::fix_fields(), ::fix_length_and_dec().
>   Some bugs are fixed using this approach,
>   some are not(Bug#57352, Bug#57703). The problem here is
>   that we have a lot of ::fix_fields(), ::fix_length_and_dec()
>   where we use Item::val_...() calls for const items.
>   
>   3. Derived tables with subquery = wrong result(Bug19077)
>   The reason of this bug is too early subquery evaluation.
>   It was fixed by adding Item::with_subselect field
>   The check of this field in appropriate places prevents
>   const item evaluation if the item have subquery.
>   The fix for Bug19077 fixes only the problem with
>   convert_constant_item() function and does not cover
>   other places(::fix_fields(), ::fix_length_and_dec() again)
>   where subqueries could be evaluated.
>   
>   Example:
>   CREATE TABLE t1 (i INT, j BIGINT);
>   INSERT INTO t1 VALUES (1, 2), (2, 2), (3, 2);
>   SELECT * FROM (SELECT MIN(i) FROM t1
>   WHERE j = SUBSTRING('12', (SELECT * FROM (SELECT MIN(j) FROM t1) t2))) t3;
>   DROP TABLE t1;
>   
>   4. Derived tables with subquery where subquery
>      is evaluated before table locking(Bug#54475, Bug#52157)
>   
>   Suggested solution is following:
>   
>   -Introduce new field LEX::context_analysis_only with the following
>    possible flags:
>    #define CONTEXT_ANALYSIS_ONLY_PREPARE 1
>    #define CONTEXT_ANALYSIS_ONLY_VIEW    2
>    #define CONTEXT_ANALYSIS_ONLY_DERIVED 4
>   -Set/clean these flags when we perform
>    context analysis operation
>   -Item_subselect::const_item() returns
>    result depending on LEX::context_analysis_only.
>    If context_analysis_only is set then we return
>    FALSE that means that subquery is non-const.
>    As all subquery types are wrapped by Item_subselect
>    it allow as to make subquery non-const when
>    it's necessary.

> ------------------------------------------------------------
> revno: 3507.1.7
> revision-id: guilhem@mysql.com-20101122085759-53uuoyqyjkh4em2m
> parent: davi.arnaut@oracle.com-20101120142951-l0f3bxmcwibcplxq
> committer: Guilhem Bichot <guilhem@mysql.com>
> branch nick: mysql-5.1-bugteam
> timestamp: Mon 2010-11-22 09:57:59 +0100
> message:
>   Fix for Bug#56138 "valgrind errors about overlapping memory when double-assigning same variable",
>   and related small fixes.

- Removed files specific to compiling on OS/2
- Removed files specific to SCO Unix packaging
- Removed "libmysqld/copyright", text is included in documentation
- Removed LaTeX headers for NDB Doxygen documentation
- Removed obsolete NDB files
- Removed "mkisofs" binaries
- Removed the "cvs2cl.pl" script
- Changed a few GPL texts to use "program" instead of "library"

ASSERT happens due to improper calculation of the max_length
in Item_func_div object, if dividend has max_length == 0 then
Item_func_div::max_length is set to 0 under some circumstances.
The fix:
If decimals == NOT_FIXED_DEC then set
Item_func_div::max_length to max possible
DOUBLE length value.

--Bug#52157 various crashes and assertions with multi-table update, stored function
--Bug#54475 improper error handling causes cascading crashing failures in innodb/ndb
--Bug#57703 create view cause Assertion failed: 0, file .\item_subselect.cc, line 846
--Bug#57352 valgrind warnings when creating view
--Recently discovered problem when a nested materialized derived table is used
  before being populated and it leads to incorrect result

We have several modes when we should disable subquery evaluation.
The reasons for disabling are different. It could be
uselessness of the evaluation as in case of 'CREATE VIEW'
or 'PREPARE stmt', or we should disable subquery evaluation
if tables are not locked yet as it happens in bug#54475, or
too early evaluation of subqueries can lead to wrong result
as it happened in Bug#19077.
Main problem is that if subquery items are treated as const
they are evaluated in ::fix_fields(), ::fix_length_and_dec()
of the parental items as a lot of these methods have
Item::val_...() calls inside.
We have to make subqueries non-const to prevent unnecessary
subquery evaluation. At the moment we have different methods
for this. Here is a list of these modes:

1. PREPARE stmt;
We use UNCACHEABLE_PREPARE flag.
It is set during parsing in sql_parse.cc, mysql_new_select() for
each SELECT_LEX object and cleared at the end of PREPARE in
sql_prepare.cc, init_stmt_after_parse(). If this flag is set
subquery becomes non-const and evaluation does not happen.

2. CREATE|ALTER VIEW, SHOW CREATE VIEW, I_S tables which
   process FRM files
We use LEX::view_prepare_mode field. We set it before
view preparation and check this flag in
::fix_fields(), ::fix_length_and_dec().
Some bugs are fixed using this approach,
some are not(Bug#57352, Bug#57703). The problem here is
that we have a lot of ::fix_fields(), ::fix_length_and_dec()
where we use Item::val_...() calls for const items.

3. Derived tables with subquery = wrong result(Bug19077)
The reason of this bug is too early subquery evaluation.
It was fixed by adding Item::with_subselect field
The check of this field in appropriate places prevents
const item evaluation if the item have subquery.
The fix for Bug19077 fixes only the problem with
convert_constant_item() function and does not cover
other places(::fix_fields(), ::fix_length_and_dec() again)
where subqueries could be evaluated.

Example:
CREATE TABLE t1 (i INT, j BIGINT);
INSERT INTO t1 VALUES (1, 2), (2, 2), (3, 2);
SELECT * FROM (SELECT MIN(i) FROM t1
WHERE j = SUBSTRING('12', (SELECT * FROM (SELECT MIN(j) FROM t1) t2))) t3;
DROP TABLE t1;

4. Derived tables with subquery where subquery
   is evaluated before table locking(Bug#54475, Bug#52157)

Suggested solution is following:

-Introduce new field LEX::context_analysis_only with the following
 possible flags:
 #define CONTEXT_ANALYSIS_ONLY_PREPARE 1
 #define CONTEXT_ANALYSIS_ONLY_VIEW    2
 #define CONTEXT_ANALYSIS_ONLY_DERIVED 4
-Set/clean these flags when we perform
 context analysis operation
-Item_subselect::const_item() returns
 result depending on LEX::context_analysis_only.
 If context_analysis_only is set then we return
 FALSE that means that subquery is non-const.
 As all subquery types are wrapped by Item_subselect
 it allow as to make subquery non-const when
 it's necessary.

            assignments and comparison in query

A query that compares assignments of the same
user variable caused Valgrind warnings: access
to freed memory region.

In case of a DECIMAL argument the assignment
operator (:=) may return a pointer to a stored
value instead of its copy when evaluated.
The next assignment to the same variable may:
 a) overwrite the stored value with a new one
    and return the same pointer or even
 b) reallocate stored value.

Thus, if we evaluate an assignment and keep
the result pointer and then evaluate another
assignment to the same variable, then the
kept result pointer of the first assignment
will point to unexpectedly changed data or
it may be a dead pointer.

That may cause wrong data or crash.

The user_var_entry::val_decimal method has
been modified to copy user variable data.

 > revision-id: gshchepa@mysql.com-20100801181236-uyuq6ewaq43rw780
 > parent: alexey.kopytov@sun.com-20100723115254-jjwmhq97b9wl932l
 > committer: Gleb Shchepa <gshchepa@mysql.com>
 > branch nick: mysql-5.1-security
 > timestamp: Sun 2010-08-01 22:12:36 +0400
 > Bug #54461: crash with longblob and union or update with subquery
 >
 > Queries may crash, if
 >   1) the GREATEST or the LEAST function has a mixed list of
 >      numeric and LONGBLOB arguments and
 >   2) the result of such a function goes through an intermediate
 >      temporary table.
 >
 > An Item that references a LONGBLOB field has max_length of
 > UINT_MAX32 == (2^32 - 1).
 >
 > The current implementation of GREATEST/LEAST returns REAL
 > result for a mixed list of numeric and string arguments (that
 > contradicts with the current documentation, this contradiction
 > was discussed and it was decided to update the documentation).
 >
 > The max_length of such a function call was calculated as a
 > maximum of argument max_length values (i.e. UINT_MAX32).
 >
 > That max_length value of UINT_MAX32 was used as a length for
 > the intermediate temporary table Field_double to hold
 > GREATEST/LEAST function result.
 >
 > The Field_double::val_str() method call on that field
 > allocates a String value.
 >
 > Since an allocation of String reserves an additional byte
 > for a zero-termination, the size of String buffer was
 > set to (UINT_MAX32 + 1), that caused an integer overflow:
 > actually, an empty buffer of size 0 was allocated.
 >
 > An initialization of the "first" byte of that zero-size
 > buffer with '\0' caused a crash.
 >
 > The Item_func_min_max::fix_length_and_dec() has been
 > modified to calculate max_length for the REAL result like
 > we do it for arithmetical operators.

and related small fixes.

Bug#55794: ulonglong options of mysqld show wrong values.

Port the few remaining system variables to the correct mechanism --
range-check in check-stage (and throw error or warning at that point
as needed and depending on STRICTness), update in update stage.
Fix some signedness errors when retrieving sysvar values for display.

The problem is dividing by const value when
the result is out of supported range.
The fix:
-return LONGLONG_MIN if the result is out of supported range for DIV operator.
-return 0 if divisor is -1 for MOD operator.

Subquery executes twice, at top level JOIN::optimize and ::execute stages.
At first execution create_sort_index() function is called and
FT_SELECT object is created and destroyed. HANDLER::ft_handler is cleaned up
in the object destructor and at second execution FT_SELECT::get_next() method
returns error.
The fix is to reinit HANDLER::ft_handler field before re-execution of subquery.

  KILL_BAD_DATA is returned

Two problems discovered with the LEAST()/GREATEST() 
functions:
1. The check for a null value should happen even 
after the second call to val_str() in the args. This is
important because two subsequent calls to the same
Item::val_str() may yield different results.
Fixed by checking for NULL value before dereferencing
the string result.

2. While looping over the arguments and evaluating them 
the loop should stop if there was an error evaluating so far
or the statement was killed. Fixed by checking for error
and bailing out.

Fixed the length of system variables to be 2^24 - 1 
as it is documented for MEDIUMBLOB instead of 
2^24.

An user assignment variable expression that's 
evaluated in a logical expression context 
(Item::val_bool()) can be pre-calculated in a 
temporary table for GROUP BY.
However when the expression value is used after the
temp table creation it was re-evaluated instead of
being read from the temp table due to a missing 
val_bool_result() method.
Fixed by implementing the method.

Queries may crash, if
  1) the GREATEST or the LEAST function has a mixed list of
     numeric and LONGBLOB arguments and
  2) the result of such a function goes through an intermediate
     temporary table.

An Item that references a LONGBLOB field has max_length of
UINT_MAX32 == (2^32 - 1).

The current implementation of GREATEST/LEAST returns REAL
result for a mixed list of numeric and string arguments (that
contradicts with the current documentation, this contradiction
was discussed and it was decided to update the documentation).

The max_length of such a function call was calculated as a
maximum of argument max_length values (i.e. UINT_MAX32).

That max_length value of UINT_MAX32 was used as a length for
the intermediate temporary table Field_double to hold
GREATEST/LEAST function result.

The Field_double::val_str() method call on that field
allocates a String value.

Since an allocation of String reserves an additional byte
for a zero-termination, the size of String buffer was
set to (UINT_MAX32 + 1), that caused an integer overflow:
actually, an empty buffer of size 0 was allocated.

An initialization of the "first" byte of that zero-size
buffer with '\0' caused a crash.

The Item_func_min_max::fix_length_and_dec() has been
modified to calculate max_length for the REAL result like
we do it for arithmetical operators.


******
Bug #54461: crash with longblob and union or update with subquery

Queries may crash, if
  1) the GREATEST or the LEAST function has a mixed list of
     numeric and LONGBLOB arguments and
  2) the result of such a function goes through an intermediate
     temporary table.

An Item that references a LONGBLOB field has max_length of
UINT_MAX32 == (2^32 - 1).

The current implementation of GREATEST/LEAST returns REAL
result for a mixed list of numeric and string arguments (that
contradicts with the current documentation, this contradiction
was discussed and it was decided to update the documentation).

The max_length of such a function call was calculated as a
maximum of argument max_length values (i.e. UINT_MAX32).

That max_length value of UINT_MAX32 was used as a length for
the intermediate temporary table Field_double to hold
GREATEST/LEAST function result.

The Field_double::val_str() method call on that field
allocates a String value.

Since an allocation of String reserves an additional byte
for a zero-termination, the size of String buffer was
set to (UINT_MAX32 + 1), that caused an integer overflow:
actually, an empty buffer of size 0 was allocated.

An initialization of the "first" byte of that zero-size
buffer with '\0' caused a crash.

The Item_func_min_max::fix_length_and_dec() has been
modified to calculate max_length for the REAL result like
we do it for arithmetical operators.

and reverse() function
      
3 problems fixed : 
1. The reported problem : caused by incorrect parsing of 
the file as ucs data resulting in wrong length of the parsed
string. Fixed by truncating the invalid trailing bytes 
(non-complete multibyte characters) when reading from the file
2. LOAD DATA when reading from a proper UCS2 file wasn't 
recognizing the new line characters. Fixed by first looking 
if a byte is a new line (or any other special) character before
reading it as a part of a multibyte character.
3. When using user variables to hold the column data in LOAD
DATA the character set of the user variable was set incorrectly
to the database charset. Fixed by setting it to the charset
specified by LOAD DATA (if any). 

DBUG_SYNC_POINT has at least one strong limitation that it's not defined
on all platforms. It has issues cooperating with @@debug.
All in all its functionality is superseded by DEBUG_SYNC facility and
there is no reason to maintain the old less flexible one.

Fixed with adding debug_sync_set_action() function as a facility to set up
a sync-action in the server sources code and re-writing existing simulations
(found 3) to use it.
Couple of tests have been reworked as well.

The patch offers a pattern for setting sync-points in replication threads
where the standard DEBUG_SYNC does not suffice to reach goals.

At the end of execution top level join execution
we cleanup this join with true argument.
It leads to underlying join cleanup(subquery) with true argument too
and to tmp_table_param->field array cleanup which is required later.
The problem is that Item_func_set_user_var does not set
result_filed which leads to unnecessary repeated excution of subquery
on final stage.
The fix is to set result_field for Item_func_set_user_var.

> ------------------------------------------------------------
> revno: 3148.8.5
> revision-id: davi.arnaut@sun.com-20091102112139-pztthzy6qj8jzomn
> parent: svoj@sun.com-20091103091902-vwszwwpfi1f4zrpn
> committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
> branch nick: 48370-5.1
> timestamp: Mon 2009-11-02 09:21:39 -0200
> message:
>   Bug#48370: Absolutely wrong calculations with GROUP BY and decimal fields when using IF
>   Bug#45261: Crash, stored procedure + decimal
>   
>   Revert fix for Bug#45261 due to unforeseen bugs.

Bug #48370  Absolutely wrong calculations with GROUP BY and
  decimal fields when using IF

Added the test cases in the above two bugs for regression
testing.
Added additional tests that demonstrate a incomplete fix.
Added a new factory method for Field_new_decimal to 
create a field from an (decimal returning) Item.
In the new method made sure that all the precision and 
length variables are capped in a proper way. 
This is required because Item's can have larger precision
than the decimal fields and thus need to be capped when
creating a field based on an Item type.
Fixed the wrong typecast to Item_decimal.

Bug#45261: Crash, stored procedure + decimal

Revert fix for Bug#45261 due to unforeseen bugs.

with gcc 4.3.2
      
This is the fifth patch cleaning up more GCC warnings about
variables used before initialized using the new macro
UNINIT_VAR().

with gcc 4.3.2
      
This patch fixes a number of GCC warnings about variables used
before initialized. A new macro UNINIT_VAR() is introduced for
use in the variable declaration, and LINT_INIT() usage will be
gradually deprecated. (A workaround is used for g++, pending a
patch for a g++ bug.)
      
GCC warnings for unused results (attribute warn_unused_result)
for a number of system calls (present at least in later
Ubuntus, where the usual void cast trick doesn't work) are
also fixed.

The problem was that creating a DECIMAL column from a decimal
value could lead to a failed assertion as decimal values can
have a higher precision than those attached to a table. The
assert could be triggered by creating a table from a decimal
with a large (> 30) scale. Also, there was a problem in
calculating the number of digits in the integral and fractional
parts if both exceeded the maximum number of digits permitted
by the new decimal type.

The solution is to ensure that truncation procedure is executed
when deducing a DECIMAL column from a decimal value of higher
precision. If the integer part is equal to or bigger than the
maximum precision for the DECIMAL type (65), the integer part
is truncated to fit and the fractional becomes zero. Otherwise,
the fractional part is truncated to fit into the space left
after the integer part is copied.

This patch borrows code and ideas from Martin Hansson's patch.

If the log_bin_trust_function_creators option is not defined, creating a stored
function requires either one of the modifiers DETERMINISTIC, NO SQL, or READS
SQL DATA. Executing a stored function should also follows the same rules if in
STATEMENT mode. However, this was not happening and a wrong error was being
printed out: ER_BINLOG_ROW_RBR_TO_SBR.

The patch makes the creation and execution compatible and prints out the correct
error ER_BINLOG_UNSAFE_ROUTINE when a stored function without one of the modifiers
above is executed in STATEMENT mode.

> ------------------------------------------------------------
> revno: 2763
> revision-id: sergey.glukhov@sun.com-20090602063813-33mh88cz5vpa2jqe
> parent: alexey.kopytov@sun.com-20090601124224-zgt3yov9wou590e9
> committer: Sergey Glukhov <Sergey.Glukhov@sun.com>
> branch nick: mysql-5.0-bugteam
> timestamp: Tue 2009-06-02 11:38:13 +0500
> message:
>   Bug#45152 crash with round() function on longtext column in a derived table
>   The crash happens due to wrong max_length value which is set on
>   Item_func_round::fix_length_and_dec() stage. The value is set to
>   args[0]->max_length which is too big in case of LONGTEXT(LONGBLOB) fields.
>   The fix is to set max_length using float_length() function.

 
Using DECIMAL constants with more than 65 digits in CREATE 
TABLE ... SELECT led to bogus errors in release builds or 
assertion failures in debug builds. 
 
The problem was in inconsistency in how DECIMAL constants and 
fields are handled internally. We allow arbitrarily long 
DECIMAL constants, whereas DECIMAL(M,D) columns are limited to 
M<=65 and D<=30. my_decimal_precision_to_length() was used in 
both Item and Field code and truncated precision to 
DECIMAL_MAX_PRECISION when calculating value length without 
adjusting precision and decimals. As a result, a DECIMAL 
constant with more than 65 digits ended up having length less 
than precision or decimals which led to assertion failures. 
 
Fixed by modifying my_decimal_precision_to_length() so that 
precision is truncated to DECIMAL_MAX_PRECISION only for Field 
object which is indicated by the new 'truncate' parameter. 
 
Another inconsistency fixed by this patch is how DECIMAL 
constants and expressions are handled for CREATE ... SELECT. 
create_tmp_field_from_item() (which is used for constants) was 
changed as a part of the bugfix for bug #24907 to handle long 
DECIMAL constants gracefully. Item_func::tmp_table_field() 
(which is used for expressions) on the other hand was still 
using a simplistic approach when creating a Field_new_decimal 
from a DECIMAL expression.