into bk-internal.mysql.com:/data0/bk/mysql-5.0-opt
BitKeeper/etc/gone:
auto-union
mysys/my_getopt.c:
Auto merged
sql/field.h:
Auto merged
sql/item.cc:
Auto merged
sql/item_cmpfunc.cc:
Auto merged
sql/item_cmpfunc.h:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/sql_prepare.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/table.cc:
Auto merged
mysql-test/r/select.result:
Manual merge
mysql-test/t/select.test:
Manual merge
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-4.1-maint
sql/item.cc:
Auto merged
sql/item_cmpfunc.cc:
Auto merged
sql/item_cmpfunc.h:
Auto merged
sql/sql_select.cc:
Auto merged
operations)
Before this change, the boolean predicates:
- X IS TRUE,
- X IS NOT TRUE,
- X IS FALSE,
- X IS NOT FALSE
were implemented by expanding the Item tree in the parser, by using a
construct like:
Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>)
Each <value> was a constant integer, either 0 or 1.
A bug in the implementation of the function IF(a, b, c), in
Item_func_if::fix_length_and_dec(), would cause the following :
When the arguments b and c are both unsigned, the result type of the
function was signed, instead of unsigned.
When the result of the if function is signed, space for the sign could be
counted twice (in the max() expression for a signed argument, and in the
total), causing the member max_length to be too high.
An effect of this is that the final type of IF(x, int(1), int(1)) would be
int(2) instead of int(1).
With this fix, the problems found in Item_func_if::fix_length_and_dec()
have been fixed.
While it's semantically correct to represent 'X IS TRUE' with
Item_func_if(Item_func_ifnull(X, <value>), <value>, <value>),
there are however more problems with this construct.
a)
Building the parse tree involves :
- creating 5 Item instances (3 ints, 1 ifnull, 1 if),
- creating each Item calls my_pthread_getspecific_ptr() once in the operator
new(size), and a second time in the Item::Item() constructor, resulting
in a total of 10 calls to get the current thread.
Evaluating the expression involves evaluating up to 4 nodes at runtime.
This representation could be greatly simplified and improved.
b)
Transforming the parse tree internally with if(ifnull(...)) is fine as long
as this transformation is internal to the server implementation.
With views however, the result of the parse tree is later exposed by the
::print() functions, and stored as part of the view definition.
Doing this has long term consequences:
1)
The original semantic 'X IS TRUE' is lost, and replaced by the
if(ifnull(...)) expression. As a result, SHOW CREATE VIEW does not restore
the original code.
2)
Should a future version of MySQL implement the SQL BOOLEAN data type for
example, views created today using 'X IS NULL' can be exported using
mysqldump, and imported again. Such views would be converted correctly and
automatically to use a BOOLEAN column in the future version.
With 'X IS TRUE' and the current implementations, views using these
"boolean" predicates would not be converted during the export/import, and
would use integer columns instead.
The difference traces back to how SHOW CREATE VIEW preserves 'X IS NULL' but
does not preserve the 'X IS TRUE' semantic.
With this fix, internal representation of 'X IS TRUE' booleans predicates
has changed, so that:
- dedicated Item classes are created for each predicate,
- only 1 Item is created to represent 1 predicate
- my_pthread_getspecific_ptr() is invoked 1 time instead of 10
- SHOW CREATE VIEW preserves the original semantic, and prints 'X IS TRUE'.
Note that, because of the fix in Item_func_if, views created before this fix
will:
- correctly use a int(1) type instead of int(2) for boolean predicates,
- incorrectly print the if(ifnull(...), ...) expression in SHOW CREATE VIEW,
since the original semantic (X IS TRUE) has been lost.
- except for the syntax used in SHOW CREATE VIEW, these views will operate
properly, no action is needed.
Views created after this fix will operate correctly, and will preserve the
original code semantic in SHOW CREATE VIEW.
mysql-test/r/func_if.result:
IF(x, unsigned, unsigned) should be unsigned.
mysql-test/r/view.result:
Preserve the semantic of 'X IS [NOT] (TRUE|FALSE)' boolean predicates.
mysql-test/t/func_if.test:
IF(x, unsigned, unsigned) should be unsigned.
mysql-test/t/view.test:
Preserve the semantic of 'X IS [NOT] (TRUE|FALSE)' boolean predicates.
sql/item_cmpfunc.cc:
Preserve the semantic of 'X IS [NOT] (TRUE|FALSE)' boolean predicates.
IF(x, unsigned, unsigned) should be unsigned.
sql/item_cmpfunc.h:
Preserve the semantic of 'X IS [NOT] (TRUE|FALSE)' boolean predicates.
sql/sql_yacc.yy:
Preserve the semantic of 'X IS [NOT] (TRUE|FALSE)' boolean predicates.
ENUMs weren't allowed to have character 0xff, a perfectly good character in some locales.
This was circumvented by mapping 0xff in ENUMs to ',', thereby prevent actual commas from
being used. Now if 0xff makes an appearance, we find a character not used in the enum and
use that as a separator. If no such character exists, we throw an error.
Any solution would have broken some sort of existing behaviour. This solution should
serve both fractions (those with 0xff and those with ',' in their enums), but
WILL REQUIRE A DUMP/RESTORE CYCLE FROM THOSE WITH 0xff IN THEIR ENUMS. :-/
That is, mysqldump with their current server, and restore when upgrading to one with
this patch.
mysql-test/r/type_enum.result:
Bug#24660: "enum" field type definition problem
Show that enums can now contain NAMES_SEP_CHAR (0xff, which is a perfectly respectable
char in some locales), or ',', or both.
mysql-test/t/type_enum.test:
Bug#24660: "enum" field type definition problem
Show that enums can now contain NAMES_SEP_CHAR (0xff, which is a perfectly respectable
char in some locales), or ',', or both.
sql/table.cc:
Bug#24660: "enum" field type definition problem
Revert fix for Bug#20922.
sql/unireg.cc:
Bug#24660: "enum" field type definition problem
Use a field-separator for ENUM-values that is not part of those values. If impossible,
throw error.
The crash happens because second filling of the same I_S table happens in
case of subselect with order by. table->sort.io_cache previously allocated
in create_sort_index() is deleted during second filling
(function get_schema_tables_result). There are two places where
I_S table can be filled: JOIN::exec and create_sort_index().
To fix the bug we should check if the table was already filled
in one of these places and skip processing of the table in second.
mysql-test/r/information_schema.result:
test case
mysql-test/t/information_schema.test:
test case
sql/mysql_priv.h:
added new parameter 'executed_place' to function get_schema_tables_result()
sql/sql_select.cc:
added new parameter 'executed_place' to function get_schema_tables_result()
sql/sql_show.cc:
added more accurate check for cases when we need to refresh I_S table
sql/table.cc:
added more accurate check for cases when we need to refresh I_S table
sql/table.h:
added more accurate check for cases when we need to refresh I_S table
Some fields (GEOMETRY first of all) can't be handled properly in this
case at all. So we return an error in this case
mysql-test/r/default.result:
result fixed
mysql-test/r/gis.result:
result fixed
mysql-test/t/default.test:
VIEW test added
mysql-test/t/gis.test:
testcase added
sql/item.cc:
set_defaults() changed with the 'reset()'
The function make_unireg_sortorder ignored the fact that any
view field is represented by a 'ref' object.
This could lead to wrong results for the queries containing
both GROUP BY and ORDER BY clauses.
mysql-test/r/view.result:
Added a test case for bug #26209.
mysql-test/t/view.test:
Added a test case for bug #26209.
Post fix for bug#12122.
information_schema.result:
Corrected test case after fixing bug#12122.
sql/sql_view.cc:
Post fix for bug#12122.
mysql-test/r/information_schema.result:
Corrected test case after fixing bug#12122.
A wrong order of statements in QUICK_GROUP_MIN_MAX_SELECT::reset
caused a crash when a query with DISTINCT was executed by a loose scan
for an InnoDB table that had been emptied.
mysql-test/r/innodb_mysql.result:
Added a test case for bug #26159.
mysql-test/t/innodb_mysql.test:
Added a test case for bug #26159.
sql/opt_range.cc:
Fixed bug #26159.
A wrong order of statements in QUICK_GROUP_MIN_MAX_SELECT::reset
caused a crash when a query with DISTINCT was executed by a loose scan
for an InnoDB table that had been emptied.
For an empty table quick_prefix_select->reset() was not called at all
and thus some important initialization steps were missing.
present.
A view created with CREATE VIEW ... ORDER BY ... cannot be resolved with
the MERGE algorithm, even when no other part of the CREATE VIEW statement
would require the view to be resolved using the TEMPTABLE algorithm.
The check for presence of the ORDER BY clause in the underlying select is
removed from the st_lex::can_be_merged() function.
The ORDER BY list of the underlying select is appended to the ORDER BY list
mysql-test/t/view.test:
Added a test case for bug#12122: Views with ORDER BY can't be resolved using MERGE algorithm.
mysql-test/r/view.result:
Added a test case for bug#12122: Views with ORDER BY can't be resolved using MERGE algorithm.
sql/sql_lex.cc:
Bug#12122: Views with ORDER BY can't be resolved using MERGE algorithm.
The st_lex::can_be_merged() function now allows views with the ORDER BY
clause to be resolved using MERGE algorithm. The ORDER BY list of the view
is appended to the ORDER BY list of the embedding select.
Objects of the class Item_equal contain an auxiliary member
eval_item of the type cmp_item that is used only for direct
evaluation of multiple equalities. Currently a multiple equality
is evaluated directly only in the cases when the equality holds
at most for one row in the result set.
The compare collation of eval_item was determined incorectly.
It could lead to returning incorrect results for some queries.
mysql-test/r/join_outer.result:
Added a test case for bug #26017.
mysql-test/t/join_outer.test:
Added a test case for bug #26017.
sql/item_cmpfunc.cc:
Fixed bug #26017.
Objects of the class Item_equal contain an auxiliary member
eval_item of the type cmp_item that is used only for direct
evaluation of multiple equalities. Currently a multiple equality
is evaluated directly only in the cases when the equality holds
at most for one row in the result set.
The compare collation of eval_item was determined incorrectly.
It could lead to returning incorrect results for some queries.
sql/item_cmpfunc.h:
Fixed bug #26017.
Removed the cmp_collation member from the Item_equal class as useless
for the current implementation of the class.
inserted.
The select_insert::send_eof() function now resets LAST_INSERT_ID variable if
no rows were inserted.
mysql-test/t/insert_select.test:
Added a test case for bug#23170: LAST_INSERT_ID isn't reset to 0 in INSERT .. SELECT when no rows were inserted.
mysql-test/r/insert_select.result:
Added a test case for bug#23170: LAST_INSERT_ID isn't reset to 0 in INSERT .. SELECT when no rows were inserted.
sql/sql_insert.cc:
Bug#23170: LAST_INSERT_ID isn't reset to 0 in INSERT .. SELECT when no rows were
inserted.The select_insert::send_eof() function now resets LAST_INSERT_ID variable if
no rows were inserted.
"update existingtable set anycolumn=nonexisting order by nonexisting" would crash
the server.
Though we would find the reference to a field, that doesn't mean we can then use
it to set some values. It could be a reference to another field. If it is NULL,
don't try to use it to set values in the Item_field and instead return an error.
Over the previous patch, this signals an error at the location of the error, rather
than letting the subsequent deref signal it.
mysql-test/r/order_by.result:
Verify that all permutations work.
mysql-test/t/order_by.test:
Verify that all permutations work.
sql/item.cc:
When the field is NULL, don't dereference it when we set_field().
Instead, raise an error.
The problem is (most probably) caused by whole server shutting down before a
slave thread terminates correctly. Fixing this requires fixing server shutdown
code which has been done in 5.1 tree. Thus we ignore the issue in 5.0 assuming
that it is fixed in 5.1.
mysql-test/valgrind.supp:
Added a suppresion rule.
"INSERT... ON DUPLICATE KEY UPDATE skips auto_increment values".
When in an INSERT ON DUPLICATE KEY UPDATE, using
an autoincrement column, we inserted some autogenerated values and
also updated some rows, some autogenerated values were not used
(for example, even if 10 was the largest autoinc value in the table
at the start of the statement, 12 could be the first autogenerated
value inserted by the statement, instead of 11). One autogenerated
value was lost per updated row. Led to exhausting the range of the
autoincrement column faster.
Bug introduced by fix of BUG#20188; present since 5.0.24 and 5.1.12.
This bug breaks replication from a pre-5.0.24 master.
But the present bugfix, as it makes INSERT ON DUP KEY UPDATE
behave like pre-5.0.24, breaks replication from a [5.0.24,5.0.34]
master to a fixed (5.0.36) slave! To warn users against this when
they upgrade their slave, as agreed with the support team, we add
code for a fixed slave to detect that it is connected to a buggy
master in a situation (INSERT ON DUP KEY UPDATE into autoinc column)
likely to break replication, in which case it cannot replicate so
stops and prints a message to the slave's error log and to SHOW SLAVE
STATUS.
For 5.0.36->[5.0.24,5.0.34] replication we cannot warn as master
does not know the slave's version (but we always recommended to users
to have slave at least as new as master).
As agreed with support, I'll also ask for an alert to be put into
the MySQL Network Monitoring and Advisory Service.
mysql-test/r/rpl_insert_id.result:
results to check the bugfix; without the bugfix, you would see, in
master and slave:
"3,2" instead of "2,2" for the INSERT VALUES testcase,
"11,6,..." instead of "6,6,..." for the INSERT SELECT testcase.
mysql-test/t/rpl_insert_id.test:
testing that BUG#24432 is fixed
sql/log_event.cc:
A trick to force the master to pretend it is old and features BUG#24432.
To do fast lookups in the list of known bugs by version, we compute
the 3 X.Y.Z numbers from the master's version string and cache that
into a new member Format_description_log_event::server_version_split.
We do this computation in the event's two constructors.
A simple prevention against buffer overrun when reading the master's
version from a binlog event (assume the event is corrupted on disk,
and so the version string on disk is longer than ST_SERVER_VER_LEN
(50), then we would not get a closing 0 at the end of the class member.
sql/log_event.h:
new member to hold the "split server version" (3 numbers X.Y.Z),
and a method to compute this from the version string.
sql/slave.cc:
a function which tells, based on master's version (as found
in the Format_description event in the relay log being executed),
if master can have a certain bug. This function uses a list of
bug_id / first_version_with_bug / first_version_with_fix.
If the test is positive, a short error message is put into SHOW SLAVE
STATUS, and a verbose message is put into the slave's error log.
The caller is expected to stop the slave in this case.
sql/slave.h:
new function to test if the replication master has a bug
sql/sql_insert.cc:
Fix for BUG#24432:t he reason was a misplaced restore_auto_increment()
(misplaced when fixing BUG#20188). Indeed, when updating the row,
it is clear that the autogenerated auto_increment value will not be
used for this row (and if by "chance" the autoinc value present
in the updated row is >= to the not used autogenerated value,
adjust_next_insert_id_after_explicit_value() will fix next_insert_id).
We also add code for a fixed slave to detect that it is connected to
a buggy master (in which case it cannot replicate so stops).
mysql-test/r/rpl_known_bugs_detection.result:
see that SHOW SLAVE STATUS prints information that slave found a bug
in master, and does not execute the dangerous event (table stays
empty).
mysql-test/t/rpl_known_bugs_detection-master.opt:
pass debug symbol to make the master pretend it has BUG#24432
mysql-test/t/rpl_known_bugs_detection.test:
new test to see if bug detection by slave works
into mysql.com:/home/ram/work/b25301/b25301.5.0
mysql-test/r/date_formats.result:
Auto merged
sql-common/my_time.c:
Merging.
Reverted fix for 19370 DateTime datatype in MySQL has two bugs in it
as it's not a bug.
The 0000 year is valid.
The ISO standard for "Representation of dates and times" says:
"Calendar years are numbered in ascending order according to the
Gregorian calendar by values in the range [0000] to [9999]."
Reverted fix for 21789: DATETIME with 0000-00-00 11:22:33 should be invalid, but is accepted
as it's not a bug.
Fix for 19370: DateTime datatype in MySQL has two bugs in it
will be reverted during 4.1 -> 5.0 merging as it was pushed to the
5.0 tree.
mysql-test/r/date_formats.result:
Fix for bug #25301: Non-zero dates with year 0000 are invalid
- reverted fix for bug #21789: DATETIME with 0000-00-00 11:22:33 should be invalid, but is accepted
sql-common/my_time.c:
Fix for bug #25301: Non-zero dates with year 0000 are invalid
- reverted fix for bug #21789: DATETIME with 0000-00-00 11:22:33 should be invalid, but is accepted
View check option clauses were ignored for updates of multi-table
views when the updates could not be performed on fly and the rows
to update had to be put into temporary tables first.
mysql-test/r/view.result:
Added a test case for bug #25931.
mysql-test/t/view.test:
Added a test case for bug #25931.
Adjusted another existed test case to have the correct result.
sql/sql_update.cc:
Fixed bug #25931.
View check option clauses were ignored for updates of multi-table
views when the updates could not be performed on fly and the rows
to update had to be put into temporary tables first.
Added the required check to multi_update::do_updates to fix the problem.
"CONNECTION is a reserved keyword"
Allow connection to be used as an ordinary identifier
Tests included.
mysql-test/r/keywords.result:
test that CONNECTION may be used as ordinary identifier
test that CONNECTION may be used in stored procedure.
mysql-test/t/keywords.test:
test that CONNECTION may be used as ordinary identifier
test that CONNECTION may be used in stored procedure.
sql/sql_yacc.yy:
Set CONNECTION as an unreserved keyword
into mysql.com:/windows/Linux_space/MySQL/mysql-5.0-ndb
ndb/include/ndbapi/NdbIndexScanOperation.hpp:
Auto merged
ndb/include/ndbapi/NdbScanOperation.hpp:
Auto merged
ndb/src/ndbapi/NdbScanOperation.cpp:
Auto merged
sql/ha_ndbcluster.cc:
Auto merged
sql/ha_ndbcluster.h:
Auto merged
with a column of the DATETIME type could return a wrong
result set if the WHERE clause included a BETWEEN condition
on the column.
Fixed the method Item_func_between::fix_length_and_dec
where the aggregation type for BETWEEN predicates calculated
incorrectly if the first argument was a view column of the
DATETIME type.
mysql-test/r/view.result:
Added a test case for bug #26124.
mysql-test/t/view.test:
Added a test case for bug #26124.
Before this change, a local variables in stored procedures / stored functions
or triggers, when declared with a type of bit(N), would not evaluate their
value properly.
The problem was that the data was incorrectly typed as a string,
causing for example bit b'1', implemented as a byte 0x01, to be interpreted
as a string starting with the character 0x01. This later would cause
implicit conversions to integers or booleans to fail.
The root cause of this problem was an incorrect translation between field
types, like bit(N), and internal types used when representing values in Item
objects.
Also, before this change, the function HEX() would sometime print extra "0"
characters when invoked with bit(N) values.
With this fix, the type translation (sp_map_result_type, sp_map_item_type)
has been changed so that bit(N) fields are represented with integer values.
A consequence is that, for the function HEX(), when called with a stored
procedure local variable of type bit(N) as argument, HEX() is provided with an
integer instead of a string, and therefore does not print "0" padding.
A test case for Bug 12976 was present in the test suite, and has been updated.
mysql-test/r/sp-vars.result:
Local stored procedure variables of type bit(N) are integer values.
mysql-test/t/sp-vars.test:
Local stored procedure variables of type bit(N) are integer values.
sql/sp_head.cc:
Local stored procedure variables of type bit(N) are integer values.
updated.
INSERT ... ON DUPLICATE KEY UPDATE reports that a record was updated when
the duplicate key occurs even if the record wasn't actually changed
because the update values are the same as those in the record.
Now the compare_record() function is used to check whether the record was
changed and the update of a record reported only if the record differs
from the original one.
sql/sql_update.cc:
Bug#19978: INSERT .. ON DUPLICATE erroneously reports some records were
updated.
The compare_record() function was changed to non-static one.
sql/sql_insert.cc:
Bug#19978: INSERT .. ON DUPLICATE erroneously reports some records were
updated.
Now the compare_record() function is used to check whether the record was
changed and the update of a record reported only if the record differs
from the original one.
sql/mysql_priv.h:
Bug#19978: INSERT .. ON DUPLICATE erroneously reports some records were
updated.
Added the prototype of the compare_record() function.
mysql-test/t/insert_select.test:
Added a test case for bug#19978: INSERT .. ON DUPLICATE erroneously reports
some records were updated.
mysql-test/r/insert_select.result:
Added a test case for bug#19978: INSERT .. ON DUPLICATE erroneously reports
some records were updated.
BitKeeper/etc/ignore:
Added mysql-test/mysql-test-run-shell to the ignore list
mysql-test/suite/funcs_2/include/check_charset.inc:
finished files with newline
- Small difference in output from 'X509_NAME_Oneline' between OpenSSL and yaSSL. OpenSSL uses
an extension that allow's the email adress of the cert holder.
- Imported patch for yaSSL "add email to DN output"
extra/yassl/taocrypt/src/asn.cpp:
Import patch yassl.diff
mysql-test/r/openssl_1.result:
Update result file
mysql-test/t/openssl_1.test:
Update test to include "emailAddress=" tag in the required SUBJECT for grant.
