Commit graph

717 commits

Author SHA1 Message Date
monty@mysql.com/nosik.monty.fi
e53a73e26c Fixed a lot of compiler warnings and errors detected by Forte C++ on Solaris
Faster thr_alarm()
Added 'Opened_files' status variable to track calls to my_open()
Don't give warnings when running mysql_install_db
Added option --source-install to mysql_install_db

I had to do the following renames() as used polymorphism didn't work with Forte compiler on 64 bit systems
index_read()      -> index_read_map()
index_read_idx()  -> index_read_idx_map()
index_read_last() -> index_read_last_map()
2007-08-13 16:11:25 +03:00
gkodinov/kgeorge@magare.gmz
f6225e2048 Merge magare.gmz:/home/kgeorge/mysql/work/mysql-5.0-opt
into  magare.gmz:/home/kgeorge/mysql/work/merge-5.0-5.1-opt
2007-07-18 15:56:29 +03:00
evgen@moonbone.local
17654758a4 item_cmpfunc.cc:
A typo fixed.
2007-07-16 01:03:58 +04:00
evgen@moonbone.local
49db78b382 item_cmpfunc.cc:
Fixed compiler warning.
2007-07-16 00:59:47 +04:00
evgen@moonbone.local
9dc929f2b4 item_cmpfunc.cc:
A comment changed.
2007-07-15 23:40:57 +04:00
evgen@moonbone.local
975d22327e Extended fix for the bug#29555.
The get_time_value function is added. It is used to obtain TIME values both
from items the can return time as an integer and from items that can return
time only as a string.
The Arg_comparator::compare_datetime function now uses pointer to a getter
function to obtain values to compare. Now this function is also used for
comparison of TIME values.
The get_value_func variable is added to the Arg_comparator class.
It points to a getter function for the DATE/DATETIME/TIME comparator.
2007-07-15 21:51:36 +04:00
gshchepa/uchum@gleb.loc
1674d8dc35 Merge gleb.loc:/home/uchum/work/bk/5.0-opt
into  gleb.loc:/home/uchum/work/bk/5.1-opt
2007-07-13 19:36:10 +05:00
evgen@moonbone.local
1b1464ba30 Bug#29739: Incorrect time comparison in BETWEEN.
Time values were compared by the BETWEEN function as strings. This led to a
wrong result in cases when some of arguments are less than 100 hours and other
are greater.

Now if all 3 arguments of the BETWEEN function are of the TIME type then
they are compared as integers.
2007-07-12 23:09:55 +04:00
evgen@moonbone.local
df9c376e72 Bug#29555: Comparing time values as strings may lead to a wrong result.
Time values were compared as strings. This led to a wrong comparison
result when comparing values one of which is under 100 hours and another is
over 100 hours.

Now when the Arg_comparator::set_cmp_func function sees that both items to
compare are of the TIME type it sets the comparator to the
Arg_comparator::compare_e_int or the Arg_comparator::compare_int_unsigned
functions.
2007-07-11 23:18:02 +04:00
holyfoot/hf@hfmain.(none)
0d7168602d Merge bk@192.168.21.1:mysql-5.1-opt
into  mysql.com:/home/hf/work/27084/my51-27084
2007-06-25 14:28:30 +05:00
holyfoot/hf@hfmain.(none)
1e9373fd60 Merge bk@192.168.21.1:mysql-5.1
into  mysql.com:/d2/hf/mrg/mysql-5.1-opt
2007-06-14 16:42:43 +05:00
holyfoot/hf@hfmain.(none)
8ccc50b303 Merge bk@192.168.21.1:mysql-5.0
into  mysql.com:/d2/hf/mrg/mysql-5.0-opt
2007-06-14 16:41:10 +05:00
evgen@moonbone.local
dcc1d8229b item_cmpfunc.cc, field.cc, sql_insert.cc, sql_class.h, sql_yacc.yy:
Post merge fix.
2007-06-11 13:38:37 +04:00
evgen@moonbone.local
a52c981d6a Merge moonbone.local:/mnt/gentoo64/work/test-5.0-opt-mysql
into  moonbone.local:/mnt/gentoo64/work/test-5.1-opt-mysql
2007-06-11 00:16:00 +04:00
tsmith@quadxeon.mysql.com
0ca0984f59 Merge tsmith@bk-internal.mysql.com:/home/bk/mysql-5.1
into  quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/jun05/51
2007-06-05 23:06:43 +02:00
tsmith@quadxeon.mysql.com
d2fe24d1ef Merge tsmith@bk-internal.mysql.com:/home/bk/mysql-5.0
into  quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/jun05/50
2007-06-05 23:04:40 +02:00
evgen@moonbone.local
0a91c7ccca Bug#28778: Wrong result of BETWEEN when comparing a DATETIME field with an
integer constants.

This bug is introduced by the fix for bug#16377. Before the fix the 
Item_func_between::fix_length_and_dec method converted the second and third
arguments to the type of the first argument if they were constant and the first
argument is of the DATE/DATETIME type. That approach worked well for integer
constants and sometimes produced bad result for string constants. The fix for
the bug#16377 wrongly removed that code at all and as a result of this the
comparison of a DATETIME field and an integer constant was carried out in a
wrong way and sometimes led to wrong result sets.

Now the Item_func_between::fix_length_and_dec method converts the second and
third arguments to the type of the first argument if they are constant, the
first argument is of the DATE/DATETIME type and the DATETIME comparator isn't
applicable.
2007-06-06 00:25:06 +04:00
tsmith@quadxeon.mysql.com
4b93804592 Merge quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/51
into  quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/jun05/51
2007-06-05 17:51:30 +02:00
ibabaev@bk-internal.mysql.com
d460dc700a Merge bk-internal.mysql.com:/data0/bk/mysql-5.1
into  bk-internal.mysql.com:/data0/bk/mysql-5.1-opt
2007-06-01 06:33:37 +02:00
kaa@polly.local
ab37c16a5a Merge polly.local:/home/kaa/src/maint/bug28121/my50-bug28121
into  polly.local:/home/kaa/src/maint/bug28121/my51-bug28121
2007-05-31 12:21:21 +04:00
kaa@polly.local
d30872b4b2 Got rid of log_01[], because we don't really need it. Division and log_10[] can always be used instead, which is also a more precise way.
This is for bug #28121.
2007-05-30 22:47:52 +04:00
evgen@moonbone.local
75afe5cab5 Merge moonbone.local:/mnt/gentoo64/work/bk-trees/mysql-5.0-opt
into  moonbone.local:/mnt/gentoo64/work/test-5.1-opt-mysql
2007-05-30 19:35:35 +04:00
evgen@moonbone.local
268fdf5db3 Bug#28450: The Item_date_add_interval in select list may fail the field
type assertion.

The bug was introduced by the patch for bug #16377.
The "+ INTERVAL" (Item_date_add_interval) function detects its result type
by the type of its first argument. But in some cases it returns STRING
as the result type. This happens when, for example, the first argument is a 
DATE represented as string. All this makes the get_datetime_value()
function misinterpret such result and return wrong DATE/DATETIME value.
To avoid such cases in the fix for #16377 the code that detects correct result
field type on the first execution was added to the
Item_date_add_interval::get_date() function. Due to this the result
field type of the Item_date_add_interval item stored by the send_fields()
function differs from item's result field type at the moment when
the item is actually sent. It causes an assertion failure.

Now the get_datetime_value() detects that the DATE value is returned by
some item not only by checking the result field type but also by comparing
the returned value with the 100000000L constant - any DATE value should be
less than this value.
Removed result field type adjusting code from the
Item_date_add_interval::get_date() function.
2007-05-30 00:33:12 +04:00
kaa@polly.local
84c81bd534 Merge polly.local:/home/kaa/src/maint/bug28121/my50-bug28121
into  polly.local:/home/kaa/src/maint/mysql-5.0-maint
2007-05-28 14:34:36 +04:00
kaa@polly.local
57917510e5 Merge polly.local:/home/kaa/src/maint/bug28121/my51-bug28121
into  polly.local:/home/kaa/src/maint/mysql-5.1-maint
2007-05-28 14:30:28 +04:00
kaa@polly.local
d6e66b6434 Merge polly.local:/home/kaa/src/maint/bug28121/my50-bug28121
into  polly.local:/home/kaa/src/maint/bug28121/my51-bug28121
2007-05-28 12:52:05 +04:00
kaa@polly.local
8ac1ffdf1d Fix for bug #28121 "INSERT or UPDATE into DOUBLE(200,0) field being truncated to 31 digits"
When storing a large number to a FLOAT or DOUBLE field with fixed length, it could be incorrectly truncated if the field's length was greater than 31.

This patch also does some code cleanups to be able to reuse code which is common between Field_float::store() and Field_double::store().
2007-05-28 12:44:59 +04:00
jani@linux-th5m.site
ee4d6b4fc0 Merged from main 5.1 2007-05-24 19:47:58 +03:00
jani@a88-113-38-195.elisa-laajakaista.fi
fc3b3a0a86 Merge jamppa@bk-internal.mysql.com:/home/bk/mysql-5.1
into  a88-113-38-195.elisa-laajakaista.fi:/home/my/bk/mysql-5.1-marvel
2007-05-24 13:24:36 +03:00
tsmith@quadxeon.mysql.com
99488b31b9 Merge quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/50
into  quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/50
2007-05-21 20:50:08 +02:00
holyfoot/hf@hfmain.(none)
85d5dfedf6 Merge mysql.com:/d2/hf/mrg/mysql-5.0-opt
into  mysql.com:/d2/hf/mrg/mysql-5.1-opt
2007-05-18 20:00:49 +05:00
tsmith@siva.hindu.god
30bc713c77 Merge siva.hindu.god:/home/tsmith/m/bk/50
into  siva.hindu.god:/home/tsmith/m/bk/maint/50
2007-05-17 14:17:50 -06:00
evgen@moonbone.local
0e3c4f6729 Bug#28261: Wrong DATETIME comparison result when the GET_USER_VAR function
is involved.

The Arg_comparator::compare_datetime() comparator caches its arguments if
they are constants i.e. const_item() returns true. The
Item_func_get_user_var::const_item() returns true or false based on
the current query_id and the query_id where the variable was created.
Thus even if a query can change its value its const_item() still will return
true. All this leads to a wrong comparison result when an object of the
Item_func_get_user_var class is involved.

Now the Arg_comparator::can_compare_as_dates() and the
get_datetime_value() functions never cache result of the GET_USER_VAR()
function (the Item_func_get_user_var class).
2007-05-17 23:09:45 +04:00
msvensson@pilot.blaudden
a65d12a830 Backport of TIME->MYSQL_TIME / Y2K fixset
Made year 2000 handling more uniform
Removed year 2000 handling out from calc_days()
The above removes some bugs in date/datetimes with year between 0 and 200
Now we get a note when we insert a datetime value into a date column
For default values to CREATE, don't give errors for warning level NOTE
Fixed some compiler failures
Added library ws2_32 for windows compilation (needed if we want to compile with IOCP support)
Removed duplicate typedef TIME and replaced it with MYSQL_TIME

Better (more complete) fix for: Bug#21103 "DATE column not compared as DATE"
Fixed properly Bug#18997 "DATE_ADD and DATE_SUB perform year2K autoconversion magic on 4-digit year value"
Fixed Bug#23093 "Implicit conversion of 9912101 to date does not match cast(9912101 as date)"
2007-05-16 10:44:59 +02:00
evgen@moonbone.local
fbb2332628 Bug#28208: Wrong result of a non-const STRING function with a const DATETIME
function.

A wrong  condition was used to check that the
Arg_comparator::can_compare_as_dates() function calculated the value of the
string constant. When comparing a non-const STRING function with a constant
DATETIME function it leads to saving an arbitrary value as a cached value of
the DATETIME function.

Now the Arg_comparator::set_cmp_func() function initializes the const_value
variable to the impossible DATETIME value (-1) and this const_value is
cached only if it was changed by the Arg_comparator::can_compare_as_dates()
function.
2007-05-16 00:30:12 +04:00
monty@mysql.com/narttu.mysql.fi
088e2395f1 WL#3817: Simplify string / memory area types and make things more consistent (first part)
The following type conversions was done:

- Changed byte to uchar
- Changed gptr to uchar*
- Change my_string to char *
- Change my_size_t to size_t
- Change size_s to size_t

Removed declaration of byte, gptr, my_string, my_size_t and size_s. 

Following function parameter changes was done:
- All string functions in mysys/strings was changed to use size_t
  instead of uint for string lengths.
- All read()/write() functions changed to use size_t (including vio).
- All protocoll functions changed to use size_t instead of uint
- Functions that used a pointer to a string length was changed to use size_t*
- Changed malloc(), free() and related functions from using gptr to use void *
  as this requires fewer casts in the code and is more in line with how the
  standard functions work.
- Added extra length argument to dirname_part() to return the length of the
  created string.
- Changed (at least) following functions to take uchar* as argument:
  - db_dump()
  - my_net_write()
  - net_write_command()
  - net_store_data()
  - DBUG_DUMP()
  - decimal2bin() & bin2decimal()
- Changed my_compress() and my_uncompress() to use size_t. Changed one
  argument to my_uncompress() from a pointer to a value as we only return
  one value (makes function easier to use).
- Changed type of 'pack_data' argument to packfrm() to avoid casts.
- Changed in readfrm() and writefrom(), ha_discover and handler::discover()
  the type for argument 'frmdata' to uchar** to avoid casts.
- Changed most Field functions to use uchar* instead of char* (reduced a lot of
  casts).
- Changed field->val_xxx(xxx, new_ptr) to take const pointers.

Other changes:
- Removed a lot of not needed casts
- Added a few new cast required by other changes
- Added some cast to my_multi_malloc() arguments for safety (as string lengths
  needs to be uint, not size_t).
- Fixed all calls to hash-get-key functions to use size_t*. (Needed to be done
  explicitely as this conflict was often hided by casting the function to
  hash_get_key).
- Changed some buffers to memory regions to uchar* to avoid casts.
- Changed some string lengths from uint to size_t.
- Changed field->ptr to be uchar* instead of char*. This allowed us to
  get rid of a lot of casts.
- Some changes from true -> TRUE, false -> FALSE, unsigned char -> uchar
- Include zlib.h in some files as we needed declaration of crc32()
- Changed MY_FILE_ERROR to be (size_t) -1.
- Changed many variables to hold the result of my_read() / my_write() to be
  size_t. This was needed to properly detect errors (which are
  returned as (size_t) -1).
- Removed some very old VMS code
- Changed packfrm()/unpackfrm() to not be depending on uint size
  (portability fix)
- Removed windows specific code to restore cursor position as this
  causes slowdown on windows and we should not mix read() and pread()
  calls anyway as this is not thread safe. Updated function comment to
  reflect this. Changed function that depended on original behavior of
  my_pwrite() to itself restore the cursor position (one such case).
- Added some missing checking of return value of malloc().
- Changed definition of MOD_PAD_CHAR_TO_FULL_LENGTH to avoid 'long' overflow.
- Changed type of table_def::m_size from my_size_t to ulong to reflect that
  m_size is the number of elements in the array, not a string/memory
  length.
- Moved THD::max_row_length() to table.cc (as it's not depending on THD).
  Inlined max_row_length_blob() into this function.
- More function comments
- Fixed some compiler warnings when compiled without partitions.
- Removed setting of LEX_STRING() arguments in declaration (portability fix).
- Some trivial indentation/variable name changes.
- Some trivial code simplifications:
  - Replaced some calls to alloc_root + memcpy to use
    strmake_root()/strdup_root().
  - Changed some calls from memdup() to strmake() (Safety fix)
  - Simpler loops in client-simple.c
2007-05-10 12:59:39 +03:00
evgen@moonbone.local
fea4af6d49 item_cmpfunc.cc, type_datetime.result, type_datetime.test, item_cmpfunc.h:
After merge fix.
2007-05-08 22:28:24 +04:00
evgen@moonbone.local
df081a3a4f Merge moonbone.local:/mnt/gentoo64/work/bk-trees/mysql-5.0-opt
into  moonbone.local:/mnt/gentoo64/work/test-5.1-opt-mysql
2007-05-08 15:54:49 +04:00
evgen@moonbone.local
6ec0bc24a7 Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-5.0-opt
into  moonbone.local:/mnt/gentoo64/work/28133-bug-5.0-opt-mysql
2007-05-07 22:22:51 +04:00
evgen@moonbone.local
7d473a1a37 Bug#28133: Wrong DATE/DATETIME comparison in IN() function.
The IN function was comparing DATE/DATETIME values either as ints or as
strings. Both methods have their disadvantages and may lead to a wrong
result.

Now IN function checks whether all of its arguments has the STRING result
types and at least one of them is a DATE/DATETIME item. If so it uses either
an object of the in_datetime class or an object of the cmp_item_datetime
class to perform its work. If the IN() function arguments are rows then
row columns are checked whether the DATE/DATETIME comparator should be used
to compare them.
The in_datetime class is used to find occurence of the item to be checked
in the vector of the constant DATE/DATETIME values. The cmp_item_datetime
class is used to compare items one by one in the DATE/DATETIME context.
Both classes obtain values from items with help of the get_datetime_value()
function and cache the left item if it is a constant one.
2007-05-07 22:20:43 +04:00
holyfoot/hf@hfmain.(none)
763d4bf22e Merge mysql.com:/d2/hf/mrg/mysql-5.0-opt
into  mysql.com:/d2/hf/mrg/mysql-5.1-opt
2007-05-07 16:12:42 +05:00
evgen@moonbone.local
239f727b7e Bug#27759: Wrong DATE/DATETIME comparison in LEAST()/GREATEST() functions.
The LEAST/GREATEST functions compared DATE/DATETIME values as
strings which in some cases could lead to a wrong result.

A new member function called cmp_datetimes() is added to the
Item_func_min_max class. It compares arguments in DATETIME context
and returns index of the least/greatest argument.
The Item_func_min_max::fix_length_and_dec() function now detects when
arguments should be compared in DATETIME context and sets the newly
added flag compare_as_dates. It indicates that the cmp_datetimes() function
should be called to get a correct result.
Item_func_min_max::val_xxx() methods are corrected to call the
cmp_datetimes() function when needed.
Objects of the Item_splocal class now stores and reports correct original
field type.
2007-05-04 18:57:10 +04:00
holyfoot/hf@mysql.com/hfmain.(none)
c5625bc1ad merging fix 2007-04-30 09:25:38 +05:00
holyfoot/hf@hfmain.(none)
e0b6a9baa0 Merge bk@192.168.21.1:mysql-5.1
into  mysql.com:/d2/hf/mrg/mysql-5.1-opt
2007-04-29 18:52:14 +05:00
holyfoot/hf@mysql.com/hfmain.(none)
35ca5a4f87 merging fix 2007-04-29 18:46:06 +05:00
holyfoot/hf@mysql.com/hfmain.(none)
e2f6bd86b4 Merge bk@192.168.21.1:mysql-5.0
into  mysql.com:/d2/hf/mrg/mysql-5.0-opt
2007-04-29 18:42:50 +05:00
holyfoot/hf@hfmain.(none)
2fcebef31f Merge mysql.com:/d2/hf/mrg/mysql-5.0-opt
into  mysql.com:/d2/hf/mrg/mysql-5.1-opt
2007-04-29 13:19:32 +05:00
evgen@sunlight.local
4b5c387f5d Additional fix for the bug#27590. 2007-04-28 00:04:50 +04:00
evgen@moonbone.local
7a1c61efb6 Bug#16377: Wrong DATE/DATETIME comparison in BETWEEN function.
The BETWEEN function was comparing DATE/DATETIME values either as ints or as
strings. Both methods have their disadvantages and may lead to a wrong
result.

Now BETWEEN function checks whether all of its arguments has the STRING result
types and at least one of them is a DATE/DATETIME item. If so it sets up
two Arg_comparator obects to compare with the compare_datetime() comparator
and uses them to compare such items.

Added two Arg_comparator object members and one flag to the
Item_func_between class for the correct DATE/DATETIME comparison.
The Item_func_between::fix_length_and_dec() function now detects whether
it's used for DATE/DATETIME comparison and sets up newly added Arg_comparator
objects to do this.
The Item_func_between::val_int() now uses Arg_comparator objects to perform
correct DATE/DATETIME comparison.
The owner variable of the Arg_comparator class now can be set to NULL if the
caller wants to handle NULL values by itself.
Now the Item_date_add_interval::get_date() function ajusts cached_field type according to the detected type.
2007-04-27 00:40:35 +04:00
evgen@moonbone.local
84c47ae08f Merge moonbone.local:/mnt/gentoo64/work/27590-bug-5.0-opt-mysql
into  moonbone.local:/mnt/gentoo64/work/16377-bug-5.0-opt-mysql
2007-04-27 00:13:13 +04:00