libmysqld/examples/test-run:
mysql_embedded should be run here
libmysqld/lib_sql.cc:
thd->real_id setup added
bootstrap check added
mysql-test/t/innodb.test:
paths can be different in embedded server - replace_result added
sql/item_func.cc:
we should compare real_id-s in embedded server
Support says that memlock doesn't work on OSes other than Solaris.
Add a warning about --memlock to the crash monologue.
sql/mysqld.cc:
On a crash when --memlock was active, emit advice about the insta-
bility of that parameter.
into outpost.site:/home/cps/mysql/trees/4.1-runtime-bug9191
configure.in:
Auto merged
include/my_time.h:
Auto merged
mysql-test/r/func_time.result:
Auto merged
mysql-test/r/rename.result:
Auto merged
mysql-test/t/func_time.test:
Auto merged
sql-common/my_time.c:
Auto merged
sql/item_timefunc.cc:
Auto merged
sql/time.cc:
Auto merged
mysql-test/t/rename.test:
choose one of the race problem solutions. It was solved
differently in -runtime and mainstream
specifying DEFAULT
This was not specific to datetime. When there is no default value
for a column, and the user inserted DEFAULT, we would write
uninitialized memory to the table.
Now, insist on writing a default value, a zero-ish value, the same
one that comes from inserting NULL into a not-NULL field.
(This is, at best, really strange behavior that comes from allowing
sloppy usage, and serves as a good reason always to run one's server
in a strict SQL mode.)
mysql-test/r/default.result:
Verify that all kinds of types work, even others other than datetime.
mysql-test/t/default.test:
Verify that all kinds of types work, even others other than datetime.
sql/item.cc:
Even if we warn that there is no default value in the table definition,
we have to insert /something/.
When compiling GROUP BY Item_ref instances are dereferenced in
setup_copy_fields(), i.e. replaced with the corresponding Item_field
(if they point to one) or Item_copy_string for the other cases.
Since the Item_ref (in the Item_field case) is no longer used the information
about the aliases stored in it is lost.
Fixed by preserving the column, table and DB alias on dereferencing Item_ref
mysql-test/r/metadata.result:
Bug #20191: getTableName gives wrong or inconsistent result when using VIEWs
- test case
mysql-test/t/metadata.test:
Bug #20191: getTableName gives wrong or inconsistent result when using VIEWs
- test case
sql/item.cc:
Bug #20191: getTableName gives wrong or inconsistent result when using VIEWs
- use the table and db name to fill up the metadata for columns
sql/sql_select.cc:
Bug #20191: getTableName gives wrong or inconsistent result when using VIEWs
- preserve the field, table and DB name on dereferencing an Item_ref
As get_arg0_date() in the Item_func_last_day::get_date() returns
0000-00-00 date sometimes, we have to check ltime->month for 0 after the call.
mysql-test/r/func_time.result:
Fix for bug #23653: Crash if last_day('0000-00-00')
- test result.
mysql-test/t/func_time.test:
Fix for bug #23653: Crash if last_day('0000-00-00')
- test case.
sql/item_timefunc.cc:
Fix for bug #23653: Crash if last_day('0000-00-00')
- return error if month is 0.
- Detect if a table has field of type MYSQL_TYPE_VAR_STRING while running
"CHECK TABLE t FOR UPGRADE" and indicate it need to be fixed
with "REPAIR TABLE t".
- When running a "REPAIR TABLE t" or "ALTER TABLE t FORCE" on the above
table, install a special copy function to trim off the trailing spaces
which we safely can say that the pre 5.0 mysqld didn't put there.
mysql-test/r/varbinary.result:
Add test to see that a table with varbinary from 4.1 can be REPAIRED
mysql-test/t/varbinary.test:
Add test to see that a table with varbinary from 4.1 can be REPAIRED
sql/field_conv.cc:
Add new field copy function 'do_field_varbinary_pre50' used for copying
between MYSQL_TYPE_VAR_STRING and MYSQL_TYPE_VARCHAR. It will remove trailing
spaces from the field as MySQL <= 4.1 never stores the trailing spaces for
a MYSQL_TYPE_VAR_STRING.
Install this new copy function in ALTER TABLEs list of functions to use for
copying data during and alter if from field is a <= 4.1 varbinary and to
field is 5.0 varbinary.
sql/handler.cc:
If the table has a pre 5.0 varbinary, table not to be altered so the field
type is upgraded to 5.0 version and trailing space can be trimmed.
mysql-test/std_data/bug19371.MYD:
New BitKeeper file ``mysql-test/std_data/bug19371.MYD''
mysql-test/std_data/bug19371.MYI:
New BitKeeper file ``mysql-test/std_data/bug19371.MYI''
mysql-test/std_data/bug19371.frm:
New BitKeeper file ``mysql-test/std_data/bug19371.frm''
The problem was that any VIEW columns had always implicit derivation.
Fix: derivation is now copied from the original expression
given in VIEW definition.
For example:
- a VIEW column which comes from a string constant
in CREATE VIEW definition have now coercible derivation.
- a VIEW column having COLLATE clause
in CREATE VIEW definition have now explicit derivation.
mysql-test/r/ctype_utf8.result:
Adding test case
mysql-test/t/ctype_utf8.test:
Adding test case
sql/field.cc:
Copying derivation from item to field.
sql/field.h:
Adding derivation and methods to get/set it into Field.
sql/item.cc:
Copying derivation from field to item.
sql/item.h:
Moving "enum Derivation" declaration from item.h to mysql_priv.h
sql/mysql_priv.h:
Moving "enum Derivation" declaration from item.h to mysql_priv.h
sql/sql_select.cc:
Copying derivation from item to field in
create_tmp_field_from_item() and create_tmp_field().
on large length
Problem: Most (all) of the numeric inputs were being coerced into
int (32 bit) sized variables. Works OK for sane inputs; any input
larger than 2^32 (or 2^31 for signed vars) exihibited predictable
wrapping behavior (up to about 10^18) and then started having really
strange behaviour past that point (since the conversion to 64 bit int
from the DECIMAL type can do weird things on out of range numbers).
Solution: 1) Add many tests. 2) Convert input from (u)long type to
(u)longlong. 3) Do (sometimes multiple) sanity checks on input,
keeping in mind that sometimes a negative longlong is not a negative
longlong (if the unsigned_flag is set). 4) Emulate existing behavior
w/rt negative and "small" out-of-bounds values.
mysql-test/r/func_str.result:
Additional test results for #10963
mysql-test/t/func_str.test:
Additional test results for #10963
sql/item_func.cc:
Used larger type for counting, to avoid truncation.
sql/item_strfunc.cc:
Fix for #10963, including comments and cleaned up logic
into mysql.com:/usr/home/bar/mysql-5.0.b23451
mysql-test/r/func_gconcat.result:
after merge fix
mysql-test/t/func_gconcat.test:
after merge fix
sql/item_sum.cc:
after merge fix
Don't assume that condition that was pushed down into subquery has
produced exactly one KEY_FIELD element - it could produce several or
none at all, handle all of those cases.
- When returning metadata for scalar subqueries the actual type of the
column was calculated based on the value type, which limits the actual
type of a scalar subselect to the set of (currently) 3 basic types :
integer, double precision or string. This is the reason that columns
of types other then the basic ones (e.g. date/time) are reported as
being of the corresponding basic type.
Fixed by storing/returning information for the column type in addition
to the result type.
mysql-test/r/subselect.result:
Bug #11032: getObject() returns a String for a sub-query of type datetime
- test case
mysql-test/t/subselect.test:
Bug #11032: getObject() returns a String for a sub-query of type datetime
- test case
sql/item_subselect.cc:
Bug #11032: getObject() returns a String for a sub-query of type datetime
- store and return the field type as well in addition to result type for
single row subqueries
sql/item_subselect.h:
Bug #11032: getObject() returns a String for a sub-query of type datetime
- store and return the field type as well in addition to result type for
single row subqueries
into mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge
BitKeeper/etc/collapsed:
auto-union
mysql-test/r/ctype_utf8.result:
Auto merged
sql/field.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
into alik.:/mnt/raid/alik/MySQL/devel/5.0-merged-5.0-rt
configure.in:
Auto merged
include/my_time.h:
Auto merged
mysql-test/r/func_time.result:
Auto merged
mysql-test/r/rename.result:
Auto merged
mysql-test/t/func_time.test:
Auto merged
mysql-test/t/im_daemon_life_cycle.imtest:
Auto merged
mysql-test/t/rename.test:
Auto merged
sql-common/my_time.c:
Auto merged
sql/item_timefunc.cc:
Auto merged
sql/time.cc:
Auto merged
Problem: GROUP_CONCAT on a multi-byte column can truncate
in the middle of a multibyte character when applying
group_concat_max_len limit. It produces an invalid
multi-byte character in the result string.
The second, easier version - reusing old "warning_for_row" flag,
instead of introducing of "result_is_full" - which was
added in the previous commit.
mysql-test/r/func_gconcat.result:
Adding test case
mysql-test/t/func_gconcat.test:
Adding test case
sql/item_sum.cc:
Adding well_formed_len() call not to cut
in the middle of a multi-byte character.
The Item_func_mod objects never had maybe_null set, so users had no reason
to expect that they can be NULL, and may therefore deduce wrong results.
Now, set maybe_null.
mysql-test/r/func_test.result:
Verify that the predictions are true.
mysql-test/t/func_test.test:
Verify that the predictions are true.
sql/item_func.cc:
MOD functions may be NULL.
include/my_time.h:
we need to use it outside the my_time.cc
mysql-test/r/gis-rtree.result:
result fixed
sql-common/my_time.c:
'static' removed
sql/field.cc:
checks for invalid datetimes added
