Commit graph

352 commits

Author SHA1 Message Date
ibabaev@bk-internal.mysql.com
4bc1738be0 Merge bk-internal.mysql.com:/data0/bk/mysql-5.0
into  bk-internal.mysql.com:/data0/bk/mysql-5.0-opt
2007-06-02 00:57:25 +02:00
kostja@bodhi.(none)
d97db648a0 Fix some mysqltest warnings. 2007-06-01 17:49:01 +04:00
gkodinov/kgeorge@magare.gmz
a6ebd63479 Bug #28605: SHOW CREATE VIEW with views using stored_procedures no
longer showing SP names.
SHOW CREATE VIEW uses Item::print() methods to reconstruct the 
statement text from the parse tree.
The print() method for stored procedure calls needs allocate 
space to print the function's quoted name.
It was incorrectly calculating the length of the buffer needed 
(was too short).
Fixed to reflect the actual space needed.
2007-05-29 14:45:30 +03:00
malff/marcsql@weblab.(none)
4b0d37362b Merge weblab.(none):/home/marcsql/TREE/mysql-5.0-base
into  weblab.(none):/home/marcsql/TREE/mysql-5.0-rt-merge
2007-05-02 09:59:39 -06:00
malff/marcsql@weblab.(none)
012f841fd4 Bug#21513 (SP having body starting with quoted label rendered unusable)
Before this fix, the parser would sometime change where a token starts by
altering Lex_input_string::tok_start, which later confused the code in
sql_yacc.yy that needs to capture the source code of a SQL statement,
like to represent the body of a stored procedure.

This line of code in sql_lex.cc :

case MY_LEX_USER_VARIABLE_DELIMITER:
  lip->tok_start= lip->ptr; // Skip first `

would <skip the first back quote> ... and cause the bug reported.

In general, the responsibility of sql_lex.cc is to *find* where token are
in the SQL text, but is *not* to make up fake or incomplete tokens.
With a quoted label like `my_label`, the token starts on the first quote.
Extracting the token value should not change that (it did).

With this fix, the lexical analysis has been cleaned up to not change
lip->tok_start (in the case found for this bug).

The functions get_token() and get_quoted_token() now have an extra
parameters, used when some characters from the beginning of the token need
to be skipped when extracting a token value, like when extracting 'AB' from
'0xAB', for example, for a HEX_NUM token.

This exposed a bad assumption in Item_hex_string and Item_bin_string,
which has been fixed:

The assumption was that the string given, 'AB', was in fact preceded in
memory by '0x', which might be false (it can be preceded by "x'" and
followed by "'" -- or not be preceded by valid memory at all)

If a name is needed for Item_hex_string or Item_bin_string, the name is
taken from the original and true source code ('0xAB'), and assigned in
the select_item rule, instead of relying on assumptions related to how
memory is used.
2007-04-27 17:14:25 -06:00
df@pippilotta.erinye.com
e0f148d5f0 Fix test case that was broken for builds without InnoDB. 2007-04-25 20:23:19 +02:00
malff/marcsql@weblab.(none)
fc36313733 Merge weblab.(none):/home/marcsql/TREE/mysql-5.0-base
into  weblab.(none):/home/marcsql/TREE/mysql-5.0-rt-merge
2007-04-20 15:34:04 -06:00
anozdrin/alik@ibm.
9719af3f2b Test case for BUG#5274: Stored procedure crash if length
of CHAR variable too great.
2007-04-12 19:42:45 +04:00
jani@ua141d10.elisa.omakaista.fi
335153121b Merge jamppa@bk-internal.mysql.com:/home/bk/mysql-5.0
into  ua141d10.elisa.omakaista.fi:/home/my/bk/mysql-5.0-marvel
2007-04-12 12:50:02 +03:00
anozdrin/alik@alik.opbmk
cc83bb0784 Fix for BUG#25082: default database change on trigger
execution breaks replication.

When a stored routine is executed, we switch current
database to the database, in which the routine
has been created. When the stored routine finishes,
we switch back to the original database.

The problem was that if the original database does not
exist (anymore) after routine execution, we raised an error.

The fix is to report a warning, and switch to the NULL database.
2007-03-27 21:55:01 +04:00
thek@kpdesk.mysql.com
1381b26e36 Corrected error in test case:
- 1.84e+15 converted to unsigned bigint should be
  18400000000000000000 < 18446744073709551615.
- The test will still fail on windows, and is extracted
  into a new bug report.
2007-03-27 18:05:17 +02:00
serg@sergbook.mysql.com
237ed0c3e5 Merge bk-internal.mysql.com:/home/bk/mysql-5.0-marvel
into  sergbook.mysql.com:/usr/home/serg/Abk/mysql-5.0
2007-03-24 17:16:53 +02:00
Kristofer.Pettersson@naruto.
fe43de3929 Merge naruto.:C:/cpp/bug20777/my50-bug20777
into  naruto.:C:/cpp/mysql-5.0-runtime
2007-03-23 19:14:13 +01:00
aelkin/elkin@andrepl.(none)
9856be570a Bug #27354 stored function in where condition was always treated as const
Possible problems: function call could be eliminated from where class and only
be evaluated once; function can be evaluated during table and item setup phase which could
cause side effects not to be registered in binlog.

Fixed with introducing func_item_sp::used_tables() returning the correct table_map constant.
2007-03-22 19:17:15 +02:00
kostja@bodhi.local
a9065201d5 Merge bk-internal.mysql.com:/home/bk/mysql-5.0
into  bodhi.local:/opt/local/work/mysql-5.0-runtime
2007-03-19 23:59:53 +03:00
Kristofer.Pettersson@naruto.
05bef7884a Bug#20777 Function w BIGINT UNSIGNED shows diff. behaviour with and without --ps-protocol
- Stored procedures returning unsinged values returns signed values if
  text protocol is used. The reason is that the stored proceedure item
  Item_func_sp wasn't initializing the member variables properly based
  on the information contained in the associated result field.
- The patch is to upon field-item association, ::fix_fields, initialize
  the member variables in appropriate order.
- Field type of an Item_func_sp was hard coded to MYSQL_TYPE_VARCHAR.
  This is changed to return the type of the actual result field.
- Member function name sp_result_field was refactored to the more 
  appropriate init_result_field.
- Member function name find_and_check_access was refactored to 
  sp_check_access.
2007-03-16 14:25:11 +01:00
malff/marcsql@weblab.(none)
bef323b1d6 Bug#26503 (Illegal SQL exception handler code causes the server to crash)
Before this fix, the parser would accept illegal code in SQL exceptions
handlers, that later causes the runtime to crash when executing the code,
due to memory violations in the exception handler stack.

The root cause of the problem is instructions within an exception handler
that jumps to code located outside of the handler. This is illegal according
to the SQL 2003 standard, since labels located outside the handler are not
supposed to be visible (they are "out of scope"), so any instruction that
jumps to these labels, like ITERATE or LEAVE, should not parse.

The section of the standard that is relevant for this is :
  SQL:2003 SQL/PSM (ISO/IEC 9075-4:2003)
  section 13.1 <compound statement>,
  syntax rule 4
<quote>
  The scope of the <beginning label> is CS excluding every <SQL schema
  statement> contained in CS and excluding every
  <local handler declaration list> contained in CS. <beginning label> shall
  not be equivalent to any other <beginning label>s within that scope.
</quote>

With this fix, the C++ class sp_pcontext, which represent the "parsing
context" tree (a.k.a symbol table) of a stored procedure, has been changed
as follows:
- constructors have been cleaned up, so that only building a root node for
the tree is public; building nodes inside a tree is not public.
- a new member, m_label_scope, indicates if a given syntactic context
belongs to a DECLARE HANDLER block,
- label resolution, in the method find_label(), has been changed to
implement the restriction of scope regarding labels used in a compound
statement.

The actions in the parser, when parsing the body of a SQL exception handler,
have been changed as follows:
- the implementation of an exception handler (DECLARE HANDLER) now creates
explicitly a new sp_pcontext, to isolate the code inside the handler from
the containing compound statement context.
- registering exception handlers as a result occurs in the parent context,
see the rule sp_hcond_element
- the code in sp_hcond_list has been cleaned up, to avoid code duplication

In addition, the flags IN_SIMPLE_CASE and IN_HANDLER, declared in sp_head.h
have been removed, since they are unused and broken by design (as seen with
Bug 19194 (Right recursion in parser for CASE causes excessive stack usage,
limitation), representing a stack in a single flag is not possible.

Tests in sp-error have been added to show that illegal constructs are now
rejected.

Tests in sp have been added for code coverage, to show that ITERATE or LEAVE
statements are legal when jumping to a label in scope, inside the body of
an exception handler.
2007-03-14 12:02:32 -06:00
holyfoot/hf@mysql.com/hfmain.(none)
11dd0fa326 Merge bk@192.168.21.1:mysql-5.0
into  mysql.com:/home/hf/work/mrg/mysql-5.0-opt
2007-03-08 21:42:41 +04:00
kroki/tomash@moonlight.home
1792908381 Merge moonlight.home:/home/tomash/src/mysql_ab/mysql-5.0
into  moonlight.home:/home/tomash/src/mysql_ab/mysql-5.0-bug20492
2007-03-08 15:16:21 +03:00
evgen@moonbone.local
b81b814cd1 Bug#25373: Stored functions wasn't compared correctly which leads to a wrong
result.

For built-in functions like sqrt() function names are hard-coded and can be
compared by pointer. But this isn't the case for a used-defined stored
functions - names there are dynamical and should be compared as strings.

Now the Item_func::eq() function employs my_strcasecmp() function to compare
used-defined stored functions names.
2007-03-07 22:11:57 +03:00
tsmith@quadxeon.mysql.com
a15fe85de2 Merge tsmith@bk-internal.mysql.com:/home/bk/mysql-5.0-runtime
into  quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/mrg0306/50
2007-03-07 06:54:35 +01:00
malff/marcsql@weblab.(none)
b216d959bb Bug#8407 (Stored functions/triggers ignore exception handler)
Bug 18914 (Calling certain SPs from triggers fail)
Bug 20713 (Functions will not not continue for SQLSTATE VALUE '42S02')
Bug 21825 (Incorrect message error deleting records in a table with a
  trigger for inserting)
Bug 22580 (DROP TABLE in nested stored procedure causes strange dependency
  error)
Bug 25345 (Cursors from Functions)


This fix resolves a long standing issue originally reported with bug 8407,
which affect the behavior of Stored Procedures, Stored Functions and Trigger
in many different ways, causing symptoms reported by all the bugs listed.
In all cases, the root cause of the problem traces back to 8407 and how the
server locks tables involved with sub statements.

Prior to this fix, the implementation of stored routines would:
- compute the transitive closure of all the tables referenced by a top level
statement
- open and lock all the tables involved
- execute the top level statement
"transitive closure of tables" means collecting:
- all the tables,
- all the stored functions,
- all the views,
- all the table triggers
- all the stored procedures
involved, and recursively inspect these objects definition to find more
references to more objects, until the list of every object referenced does
not grow any more.
This mechanism is known as "pre-locking" tables before execution.
The motivation for locking all the tables (possibly) used at once is to
prevent dead locks.

One problem with this approach is that, if the execution path the code
really takes during runtime does not use a given table, and if the table is
missing, the server would not execute the statement.
This in particular has a major impact on triggers, since a missing table
referenced by an update/delete trigger would prevent an insert trigger to run.

Another problem is that stored routines might define SQL exception handlers
to deal with missing tables, but the server implementation would never give
user code a chance to execute this logic, since the routine is never
executed when a missing table cause the pre-locking code to fail.

With this fix, the internal implementation of the pre-locking code has been
relaxed of some constraints, so that failure to open a table does not
necessarily prevent execution of a stored routine.

In particular, the pre-locking mechanism is now behaving as follows:

1) the first step, to compute the transitive closure of all the tables
possibly referenced by a statement, is unchanged.

2) the next step, which is to open all the tables involved, only attempts
to open the tables added by the pre-locking code, but silently fails without
reporting any error or invoking any exception handler is the table is not
present. This is achieved by trapping internal errors with
Prelock_error_handler

3) the locking step only locks tables that were successfully opened.

4) when executing sub statements, the list of tables used by each statements
is evaluated as before. The tables needed by the sub statement are expected
to be already opened and locked. Statement referencing tables that were not
opened in step 2) will fail to find the table in the open list, and only at
this point will execution of the user code fail.

5) when a runtime exception is raised at 4), the instruction continuation
destination (the next instruction to execute in case of SQL continue
handlers) is evaluated.
This is achieved with sp_instr::exec_open_and_lock_tables()

6) if a user exception handler is present in the stored routine, that
handler is invoked as usual, so that ER_NO_SUCH_TABLE exceptions can be
trapped by stored routines. If no handler exists, then the runtime execution
will fail as expected.

With all these changes, a side effect is that view security is impacted, in
two different ways.

First, a view defined as "select stored_function()", where the stored
function references a table that may not exist, is considered valid.
The rationale is that, because the stored function might trap exceptions
during execution and still return a valid result, there is no way to decide
when the view is created if a missing table really cause the view to be invalid.

Secondly, testing for existence of tables is now done later during
execution. View security, which consist of trapping errors and return a
generic ER_VIEW_INVALID (to prevent disclosing information) was only
implemented at very specific phases covering *opening* tables, but not
covering the runtime execution. Because of this existing limitation,
errors that were previously trapped and converted into ER_VIEW_INVALID are
not trapped, causing table names to be reported to the user.
This change is exposing an existing problem, which is independent and will
be resolved separately.
2007-03-05 19:42:07 -07:00
kaa@polly.local
b7e6df7cc9 Merge polly.local:/tmp/maint/bug25137/my50-bug25137
into  polly.local:/home/kaa/src/maint/mysql-5.0-maint
2007-02-20 22:23:51 +03:00
kaa@polly.local
315819fed0 Bug#18743: Several test cases fails if "classic" configuration in 5.0
The problem happened because those tests were using "cp932" and "ucs2" without checking whether these character sets are available. This fix moves test parts to make character set specific parts be tested only if they are:
- some parts were moved to "ctype_ucs.test" and "ctype_cp932.test"
- some parts were moved to the newly added tests "innodb-ucs2.test", "mysqlbinglog-cp932.test" and "sp-ucs2.test"
2007-02-19 13:57:06 +03:00
tsmith@siva.hindu.god
244b2004ee Merge siva.hindu.god:/home/tsmith/m/bk/mrg-jan17/50
into  siva.hindu.god:/home/tsmith/m/bk/mrg-jan17/maint/50
2007-01-18 10:06:36 -07:00
kostja@bodhi.local
d7a63c0f6a Manual merge. 2007-01-15 13:10:07 +03:00
kaa@polly.local
4162e009cb Fix for bug #24117 "server crash on a FETCH with a cursor on a table which is not in the table cache"
Problem:
When creating a temporary field for a temporary table in create_tmp_field_from_field(), a resulting field is created as an exact copy of an original one (in Field::new_field()). However, Field_enum and Field_set contain a pointer (typelib) to memory allocated in the parent table's MEM_ROOT, which under some circumstances may be deallocated later by the time a temporary table is used.

Solution:
Override the new_field() method for Field_enum and Field_set and create a separate copy of the typelib structure in there.
2006-12-14 20:58:07 +03:00
kostja@bodhi.local
92f1c76236 Post-merge fixes for Bug#4968 "Stored procedure crash if cursor opened
on altered table" and Bug#19733 "Repeated alter, or repeated 
create/drop, fails"
2006-12-12 01:50:12 +03:00
andrey@example.com
d1e5cfd66f Merge ahristov@bk-internal.mysql.com:/home/bk/mysql-5.0-maint
into  example.com:/work/bug23760/my50
2006-11-14 20:48:48 +01:00
andrey@example.com
9299fd6715 Fix for bug#23760 ROW_COUNT() and store procedure not owrking together
The problem was that THD::row_count_func was zeroed too. It was zeroed
as a fix for bug 4905 "Stored procedure doesn't clear for "Rows affected"
However, the proper solution is not to zero, because THD::row_count_func has
been set to -1 already in mysql_execute_command(), a later fix, which obsoletes
the incorrect fix of #4095
2006-11-14 18:40:11 +01:00
cmiller@zippy.cornsilk.net
af5acac047 Merge bk-internal.mysql.com:/home/bk/mysql-5.0
into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-maint
2006-11-02 17:39:52 -05:00
malff/marcsql@weblab.(none)
ea0998caca Bug#20028 (Function with select return no data)
This patch reverts a change introduced by Bug 6951, which incorrectly
set thd->abort_on_warning for stored procedures.

As per internal discussions about the SQL_MODE=TRADITIONAL,
the correct behavior is to *not* abort on warnings even inside an INSERT/UPDATE
trigger.

Tests for Stored Procedures, Stored Functions, Triggers involving SQL_MODE
have been included or revised, to reflect the intended behavior.

(reposting approved patch, to work around source control issues, no review needed)
2006-10-19 11:39:51 -07:00
msvensson@neptunus.(none)
179c17adfa Merge neptunus.(none):/home/msvensson/mysql/bug22436/my50-bug22436
into  neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint
2006-10-19 01:01:54 +02:00
malff/marcsql@weblab.(none)
6e809b249e Bug#21462 (Stored procedures with no arguments require parenthesis)
The syntax of the CALL statement, to invoke a stored procedure, has been
changed to make the use of parenthesis optional in the argument list.
With this change, "CALL p;" is equivalent to "CALL p();".

While the SQL spec does not explicitely mandate this syntax, supporting it
is needed for practical reasons, for integration with JDBC / ODBC connectors.

Also, warnings in the sql/sql_yacc.yy file, which were not reported by Bison 2.1
but are now reported by Bison 2.2, have been fixed.

The warning found were:
bison -y -p MYSQL  -d --debug --verbose sql_yacc.yy
sql_yacc.yy:653.9-18: warning: symbol UNLOCK_SYM redeclared
sql_yacc.yy:656.9-17: warning: symbol UNTIL_SYM redeclared
sql_yacc.yy:658.9-18: warning: symbol UPDATE_SYM redeclared
sql_yacc.yy:5169.11-5174.11: warning: unused value: $2
sql_yacc.yy:5208.11-5220.11: warning: unused value: $5
sql_yacc.yy:5221.11-5234.11: warning: unused value: $5
conflicts: 249 shift/reduce

"unused value: $2" correspond to the $$=$1 assignment in the 1st {} block
in table_ref -> join_table {} {},
which does not procude a result ($$) for the rule but an intermediate $2
value for the action instead.
"unused value: $5" are similar, with $$ assignments in {} actions blocks
which are not for the final reduce.
2006-10-09 09:59:02 -07:00
msvensson@neptunus.(none)
5a15eeca7c Merge neptunus.(none):/home/msvensson/mysql/same_tools/my50-same_tools
into  neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint
2006-10-06 13:16:57 +02:00
msvensson@neptunus.(none)
f39ff057d1 Update tests and result files after running with new mysqltest that better detects problems with test files 2006-10-04 13:09:37 +02:00
dlenev@mockturtle.local
b0e896960c Fixed test-case after merge (removed duplicate part). 2006-09-29 12:27:21 +04:00
dlenev@mockturtle.local
a4ee7ec153 Merge bk-internal.mysql.com:/home/bk/mysql-5.0
into  mockturtle.local:/home/dlenev/src/mysql-5.0-rt-merge
2006-09-29 10:55:03 +04:00
msvensson@neptunus.(none)
485772e308 Bug#22436 Four tests require "innodb" to be configured, fail in "classic" build
- Disable warnings when creating the "innodb" tables if it works anyway.
 - Move test that are really innodb dependent to innodb_mysql
2006-09-28 15:13:40 +02:00
andrey@example.com
3b672c9a3c Merge ahristov@bk-internal.mysql.com:/home/bk/mysql-5.0-runtime
into  example.com:/work/mysql-5.0-runtime
2006-09-27 22:25:23 +02:00
andrey@example.com
a4093f31d8 Fix for bug#21311: Possible stack overrun if SP has non-latin1 name
There was possible stack overrun in an edge case which handles invalid body of
a SP in mysql.proc . That should be case when mysql.proc has been changed
manually. Though, due to bug 21513, it can be exploited without having access
to mysql.proc only being able to create a stored routine.
2006-09-27 21:23:17 +02:00
gkodinov@dl145s.mysql.com
2ec485f06e Merge bk-internal:/home/bk/mysql-5.0-opt
into  dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt
2006-09-18 12:20:20 +02:00
igor@rurik.mysql.com
d3d3cef88c Fixed bug #21493: crash for the second execution of a function
containing a select statement that uses an aggregating IN subquery.
Added a parameter to the function fix_prepare_information 
to restore correctly the having clause for the second execution.
Saved andor structure of the having conditions at the proper moment
before any calls of split_sum_func2 that could modify the having structure
adding new Item_ref objects. (These additions, are produced not with 
the statement mem_root, but rather with the execution mem_root.)
2006-09-16 09:50:48 -07:00
kroki/tomash@moonlight.intranet
ed0cb3e4ba BUG#21414: SP: Procedure undroppable, to some extent
The problem was that if after FLUSH TABLES WITH READ LOCK the user
issued DROP/ALTER PROCEDURE/FUNCTION the operation would fail (as
expected), but after UNLOCK TABLE any attempt to execute the same
operation would lead to the error 1305 "PROCEDURE/FUNCTION does not
exist", and an attempt to execute any stored function will also fail.

This happened because under FLUSH TABLES WITH READ LOCK we couldn't open
and lock mysql.proc table for update, and this fact was erroneously
remembered by setting mysql_proc_table_exists to false, so subsequent
statements believed that mysql.proc doesn't exist, and thus that there
are no functions and procedures in the database.

As a solution, we remove mysql_proc_table_exists flag completely.  The
reason is that this optimization didn't work most of the time anyway.
Even if open of mysql.proc failed for some reason when we were trying to
call a function or a procedure, we were setting mysql_proc_table_exists
back to true to force table reopen for the sake of producing the same
error message (the open can fail for number of reasons).  The solution
could have been to remember the reason why open failed, but that's a lot
of code for optimization of a rare case.  Hence we simply remove this
optimization.
2006-09-12 14:56:25 +04:00
kroki/tomash@moonlight.intranet
7abe938dfa BUG#20492: Subsequent calls to stored procedure yield incorrect result
if join is used

For procedures with selects that use complicated joins with ON expression
re-execution could erroneously ignore this ON expression, giving
incorrect result.

The problem was that optimized ON expression wasn't saved for
re-execution.  The solution is to properly save it.
2006-09-07 18:51:00 +04:00
andrey@example.com
85e6c3bfc1 Fix for bug#21416 SP: Recursion level higher than zero needed for non-recursive call
The following procedure was not possible if max_sp_recursion_depth is 0
create procedure show_proc() show create procedure show_proc;
  
Actually there is no recursive call but the limit is checked.
  
Solved by temporarily increasing the thread's limit just before the fetch from cache
and decreasing after that.
2006-08-24 19:36:26 +02:00
anozdrin/alik@alik.
9af756efd3 Fix for BUG#16899: Possible buffer overflow in handling of DEFINER-clause
User name (host name) has limit on length. The server code relies on these
limits when storing the names. The problem was that sometimes these limits
were not checked properly, so that could lead to buffer overflow.

The fix is to check length of user/host name in parser and if string is too
long, throw an error.
2006-08-23 21:31:00 +04:00
malff/marcsql@weblab.(none)
28ac53688f Bug#8153 (Stored procedure with subquery and continue handler, wrong result)
Implemented code review comments
Test cleanup
2006-08-22 18:58:14 -07:00
malff/marcsql@weblab.(none)
154bb53b1f Merge malff@bk-internal.mysql.com:/home/bk/mysql-5.0-runtime
into  weblab.(none):/home/marcsql/TREE/mysql-5.0-8153
2006-08-22 09:06:00 -07:00
malff/marcsql@weblab.(none)
21f00113b4 Bug#8153 (Stored procedure with subquery and continue handler, wrong result)
Before this fix,
- a runtime error in a statement in a stored procedure with no error handlers
was properly detected (as expected)
- a runtime error in a statement with an error handler inherited from a non
local runtime context (i.e., proc a with a handler, calling proc b) was
properly detected (as expected)
- a runtime error in a statement with a *local* error handler was executed
as follows :
a) the statement would succeed, regardless of the error condition, (bug)
b) the error handler would be called (as expected).

The root cause is that functions like my_messqge_sql would "forget" to set
the thread flag thd->net.report_error to 1, because of the check involving
sp_rcontext::found_handler_here().
Failure to set this flag would cause, later in the call stack,
in Item_func::fix_fields() at line 190, the code to return FALSE and consider
that executing the statement was successful.

With this fix :
- error handling code, that was duplicated in different places in the code,
is now implemented in sp_rcontext::handle_error(),
- handle_error() correctly sets thd->net.report_error when a handler is
present, regardless of the handler location (local, or in the call stack).

A test case, bug8153_subselect, has been written to demonstrate the change
of behavior before and after the fix.

Another test case, bug8153_function_a, as also been writen.
This test has the same behavior before and after the fix.
This test has been written to demonstrate that the previous expected
result of procedure bug18787, was incorrect, since select no_such_function()
should fail and therefore not produce a result.

The incorrect result for bug18787 has the same root cause as Bug#8153,
and the expected result has been adjusted.
2006-08-02 22:18:49 -07:00