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.
remove unneeded multitable_view assignment
sql_view.cc:
fix potential memorry overrun in ref_array
asssign multitable_view in time of view creation (BUG#12569)
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.
