HP-UX compiler was generating code which makes wrong conversion from double to
ulonglong which results in not using index in some cases.
Changed type cast operators odrer with which generated code makes proper
conversion.
view being created.
Item_func_timestamp_diff::func_name() were returning function name as
"timestamp_diff" thus when view was executed function parameters wasn't
properly recognized and error was raised.
"Process NATURAL and USING joins according to SQL:2003".
* Some of the main problems fixed by the patch:
- in "select *" queries the * expanded correctly according to
ANSI for arbitrary natural/using joins
- natural/using joins are correctly transformed into JOIN ... ON
for any number/nesting of the joins.
- column references are correctly resolved against natural joins
of any nesting and combined with arbitrary other joins.
* This patch also contains a fix for name resolution of items
inside the ON condition of JOIN ... ON - in this case items must
be resolved only against the JOIN operands. To support such
'local' name resolution, the patch introduces a stack of
name resolution contexts used at parse time.
NOTICE:
- This patch is not complete in the sense that
- there are 2 test cases that still do not pass -
one in join.test, one in select.test. Both are marked
with a comment "TODO: WL#2486".
- it does not include a new test specific for the task
Fixed bug #12470.
A misplaced initialization of the cond_count counter
resulted in a wrong calculation of it. This caused a memory
corruption since this counter was used as a parameter of
some memory allocation.
view.test:
Added a test case for bug #12470.
Fixed bug #12382.
INSERT statement effectively changed thd->set_query_id to 0,
while SELECT statement changed it to 0. As a result
the insert_fields function that expanded '*' was called
with different values of thd->set_query_id for the query
SELECT * FROM view depending on whether it was run after
an INSERT or after a SELECT statement. This was corrected
by restoring the old value of thd->set_query_id when
returning from the function setup_fields where possible
reset could occur.
If the value of thd->set_query_id == 0 then the fields
substituted instead of '*' were not registered as used
for bitmaps used_keys. This caused selection of an invalid
execution plan for the query SELECT * from <view>.
view.result, view.test:
Added a test case for bug #12382.
Column names weren't checked for uniqueness for subqueries.
Code for names uniqueness checking used for view creation moved into
separate function named check_duplicate_names(). It's called on
preparation of subqueries to check uniqueness of names. If duplicate names
are found then error is raised.
cause crash on update".
Let us update "thd" pointer in LEX, all its units and in LEX::result before
executing statement in trigger body, since triggers are associated with TABLE
object and because of this can be used in different threads.
When PRIMARY KEY is present ha_innobase::cmp_ref() uses it to compare refs.
After comparing part of key it moves pointers to compare next part.
For varchar parts pointers were moved only by length of parts, not including
bytes containig part length itself. This results in wrong comparision and
wrong number of deleted records.
Added a test case for bug #12392.
item_cmpfunc.cc:
Fixed bug #12392.
Missing handling of rows containing NULL components
when evaluating IN predicates caused a crash.
* Cleanup SP Cache code, now SP Cache only deletes sp_head objects in
sp_cache_flush_obsolete() invalidates all pointers to routines in the cache.
* Use new SP Cache use contract in the code.
There is no test case because it doesn't seem to be possible to cause thread races to end
the same way they end in heavy-load test. This patch removes the crash in heavy test.
- Fixed some error condtion when handling dates with 'T'
- Added extra test for bug #11867 (Wrong result with "... WHERE ROW( a, b ) IN ( SELECT DISTINCT a, b WHERE ...)" to show it's not yet fixed
- Safety fixes and cleanups
BUG #11104
Took out the offset-=delimiter_length-1 out of the for loop. It was causing
basically this:
select substring_index('the king of the the hill', 'the', -2) to not work.
The first iteration, offset would be initialised to 24, then strstr would
point at 'the king of the the* hill' ('*'means right before the
character following), returning a offset of 16. The for loop would then
decrement offset by two (3 - 1), to 14, now pointing at
"the king of th*e the hill", _skipping_ past the 'e' in the second to last
'the', and therefore strstr would never have a chance of matching the
second to last 'the', then moving on to the 'the' at the begginning of the
string!
In a nutshell, offset was being decremented by too great a value, preventing
the second to last 'the' from being ever found, hence the result of
'king of the the hill' from the query that is reported in the bug report
func_str.test:
BUG #11104
Added tests to make sure fix addresses issues in original bug report
func_str.result:
BUG #11104
New results for new tests
