Commit graph

376 commits

Author SHA1 Message Date
malff/marcsql@weblab.(none)
6e29099d43 Bug#18239 (Possible to overload internal functions with stored functions)
Bug#21025 (misleading error message when creating functions named 'x', or 'y')
Bug#22619 (Spaces considered harmful)

This change contains a fix to report warnings or errors, and multiple tests
cases.

Before this fix, name collisions between:
- Native functions
- User Defined Functions
- Stored Functions
were not systematically reported, leading to confusing behavior.

I) Native / User Defined Function

Before this fix, is was possible to create a UDF named "foo", with the same
name as a native function "foo", but it was impossible to invoke the UDF,
since the syntax "foo()" always refer to the native function.
After this fix, creating a UDF fails with an error if there is a name
collision with a native function.

II) Native / Stored Function

Before this fix, is was possible to create a SF named "db.foo", with the same
name as a native function "foo", but this was confusing since the syntax
"foo()" would refer to the native function. To refer to the Stored Function,
the user had to use the "db.foo()" syntax.
After this fix, creating a Stored Function reports a warning if there is a
name collision with a native function.

III) User Defined Function / Stored Function

Before this fix, creating a User Defined Function "foo" and a Stored Function
"db.foo" are mutually exclusive operations. Whenever the second function is
created, an error is reported. However, the test suite did not cover this
behavior.
After this fix, the  behavior is unchanged, and is now covered by test cases.

Note that the code change in this patch depends on the fix for Bug 21114.
2006-11-14 19:34:16 -07:00
kostja@bodhi.local
2fecf79536 Merge bodhi.local:/opt/local/work/mysql-5.0-runtime
into  bodhi.local:/opt/local/work/mysql-5.1-runtime-merge
2006-10-23 12:35:56 +04: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
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
dlenev@mockturtle.local
8b63a55b3a After merge fixes. 2006-09-29 21:05:12 +04:00
dlenev@mockturtle.local
5c2a51292d Merge mockturtle.local:/home/dlenev/src/mysql-5.0-rt-merge
into  mockturtle.local:/home/dlenev/src/mysql-5.1-rt-merge
2006-09-29 19:39:15 +04: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
andrey@example.com
00c54ad530 Merge ahristov@bk-internal.mysql.com:/home/bk/mysql-5.1-runtime
into  example.com:/work/mysql-5.1-runtime-fresh2
2006-09-28 09:11:22 +02:00
petr/cps@owlet.local
64c2c0cb19 Merge pchardin@bk-internal.mysql.com:/home/bk/mysql-5.1
into  mysql.com:/home/cps/mysql/trees/5.1-runtime-new
2006-09-28 04:44:55 +04: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
c4afe67ff5 Merge example.com:/work/mysql-5.0-runtime
into  example.com:/work/mysql-5.1-runtime-fresh2
2006-09-27 21:31:34 +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
kroki/tomash@moonlight.intranet
a53e628181 Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1
into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-bug21414
2006-09-27 12:22:16 +04:00
gkodinov@dl145s.mysql.com
ce8ed889d7 Merge dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt
into  dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.1
2006-09-18 12:57:20 +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
kostja@bodhi.local
ebb7070430 Merge bodhi.local:/opt/local/work/mysql-5.0-runtime-safemerge
into  bodhi.local:/opt/local/work/mysql-5.1-runtime-merge
2006-08-30 03:00:19 +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
kostja@bodhi.local
04c97488f9 Merge bodhi.local:/opt/local/work/tmp_merge
into  bodhi.local:/opt/local/work/mysql-5.1-runtime-merge
2006-08-12 21:06:51 +04:00
kroki/tomash@moonlight.intranet
b341356abd Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-merge
into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-runtine-merge
2006-08-10 16:16:16 +04:00
kroki/tomash@moonlight.intranet
aca2c3761a Merge moonlight.intranet:/home/tomash/src/mysql_ab/tmp_merge
into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-merge
2006-08-10 16:11:55 +04:00
andrey@lmy004.
9a325ac786 Merge ahristov@bk-internal.mysql.com:/home/bk/mysql-5.1-runtime
into  lmy004.:/work/mysql-5.1-runtime
2006-08-09 17:19:39 +02:00
andrey@lmy004.
76ff7fb78f Fix for bug#20701 BINARY keyword should be forbidden in stored routines
create function func() returns char(10) binary ...
is no more possible. This will be reenabled when 
bug 2676 "DECLARE can't have COLLATE clause in stored procedure"
is fixed.

Fix after 2nd review
2006-08-09 17:07:59 +02:00
kroki/tomash@moonlight.intranet
5c272816ca Merge moonlight.intranet:/home/tomash/src/mysql_ab/tmp_merge
into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.1-merge
2006-08-09 13:37:20 +04:00
andrey@lmy004.
9c59cfe4d7 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-04 12:50:49 +02: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
kostja@bodhi.local
1b145118b9 Merge bk-internal.mysql.com:/home/bk/mysql-5.0
into  bodhi.local:/opt/local/work/mysql-5.0-runtime-merge
2006-08-02 21:54:10 +04:00
evgen@moonbone.local
67c85a170a Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-5.0
into  moonbone.local:/work/tmp_merge-5.0-opt-mysql
2006-08-02 16:44:56 +04:00
kostja@bodhi.local
4bfc67fc3c Merge bk-internal.mysql.com:/home/bk/mysql-5.0
into  bodhi.local:/opt/local/work/mysql-5.0-runtime-merge
2006-08-02 14:13:01 +04:00
evgen@sunlight.local
ef4f149536 Merge sunlight.local:/local_work/tmp_merge-5.0-opt-mysql
into  sunlight.local:/local_work/tmp_merge-5.1-opt-mysql
2006-07-30 00:33:24 +04:00
anozdrin/alik@booka.
b7f403b546 Fix for BUG#16211: Stored function return type for strings is ignored.
Fix for BUG#16676: Database CHARSET not used for stored procedures

The problem in BUG#16211 is that CHARSET-clause of the return type for
stored functions is just ignored.

The problem in BUG#16676 is that if character set is not explicitly
specified for sp-variable, the server character set is used instead
of the database one.

The fix has two parts:

  - always store CHARSET-clause of the return type along with the
    type definition in mysql.proc.returns column. "Always" means that
    CHARSET-clause is appended even if it has not been explicitly
    specified in CREATE FUNCTION statement (this affects BUG#16211 only).

    Storing CHARSET-clause if it is not specified is essential to avoid
    changing character set if the database character set is altered in
    the future.

    NOTE: this change is not backward compatible with the previous releases.

  - use database default character set if CHARSET-clause is not explicitly
    specified (this affects both BUG#16211 and BUG#16676).

    NOTE: this also breaks backward compatibility.
2006-07-27 17:57:43 +04:00
msvensson@neptunus.(none)
13aba17bf3 Cset exclude: msvensson@neptunus.(none)|ChangeSet|20060721184912|58688 2006-07-26 14:27:52 +02:00
evgen@moonbone.local
4ee2e07cc0 Fixed bug#19862: Sort with filesort by function evaluates function twice
When there is no index defined filesort is used to sort the result of a
query. If there is a function in the select list and the result set should be
ordered by it's value then this function will be evaluated twice. First time to
get the value of the sort key and second time to send its value to a user.
This happens because filesort when sorts a table remembers only values of its
fields but not values of functions.
All functions are affected. But taking into account that SP and UDF functions
can be both expensive and non-deterministic a temporary table should be used 
to store their results and then sort it to avoid twice SP evaluation and to 
get a correct result.

If an expression referenced in an ORDER clause contains a SP or UDF 
function, force the use of a temporary table.

A new Item_processor function called func_type_checker_processor is added
to check whether the expression contains a function of a particular type.
2006-07-26 00:31:29 +04:00
msvensson@neptunus.(none)
be1b24fec1 Bug#21039 Transaction cache not flushed after SELECT CREATE
- Disable test case until fixed
2006-07-21 20:49:12 +02:00
kostja@bodhi.local
f22a4ce1a1 A fix and a test case for Bug#21002 "Derived table not selecting from a
"real" table fails in JOINs".

This is a regression caused by the fix for Bug 18444. 
This fix removed the assignment of empty_c_string to table->db performed 
in add_table_to_list, as neither me nor anyone else knew what it was 
there for. Now we know it and it's covered with tests: the only case 
when a table database name can be empty is when the table is a derived 
table. The fix puts the assignment back but makes it a bit more explicit.

Additionally, finally drop sp.result.orig which was checked in by mistake.
2006-07-19 22:33:19 +04:00
kroki/tomash@moonlight.intranet
5a64e5c24f Bug#21013: Performance Degrades when importing data that uses Trigger
and Stored Procedure

The essence of the bug was that for every re-execution of stored
routine or prepared statement new items for character set conversions
were created, thus increasing the number of items and the time of their
processing, and creating memory leak.

No test case is provided since current test suite can't cover such type
of bugs.
2006-07-17 14:48:40 +04:00
cmiller@zippy.(none)
9be1c70404 Merge zippy.(none):/home/cmiller/work/mysql/merge/mysql-5.1
into  zippy.(none):/home/cmiller/work/mysql/merge/mysql-5.1-new-maint
2006-07-10 13:38:22 -04:00
konstantin@bodhi.netgear
01bc761690 Merge bodhi.netgear:/opt/local/work/tmp_merge
into  bodhi.netgear:/opt/local/work/mysql-5.1-runtime-merge-with-5.0
2006-07-06 22:55:48 +04:00
cmiller@zippy.(none)
91b8b26411 Merge zippy.(none):/home/cmiller/work/mysql/merge/mysql-5.1
into  zippy.(none):/home/cmiller/work/mysql/merge/mysql-5.1-new-maint
2006-07-05 16:16:09 -04:00
konstantin@mysql.com
4d25d2154c Merge bk-internal.mysql.com:/home/bk/mysql-5.0-runtime
into  mysql.com:/opt/local/work/mysql-5.0-17199
2006-06-27 00:52:56 +04:00
konstantin@mysql.com
117b76a562 A fix and a test case for
Bug#19022 "Memory bug when switching db during trigger execution"
 Bug#17199 "Problem when view calls function from another database."
 Bug#18444 "Fully qualified stored function names don't work correctly in
            SELECT statements"

 Documentation note: this patch introduces a change in behaviour of prepared
 statements.

 This patch adds a few new invariants with regard to how THD::db should
 be used. These invariants should be preserved in future:

  - one should never refer to THD::db by pointer and always make a deep copy
    (strmake, strdup)
  - one should never compare two databases by pointer, but use strncmp or
    my_strncasecmp
  - TABLE_LIST object table->db should be always initialized in the parser or
    by creator of the object.

    For prepared statements it means that if the current database is changed
    after a statement is prepared, the database that was current at prepare
    remains active. This also means that you can not prepare a statement that
    implicitly refers to the current database if the latter is not set.
    This is not documented, and therefore needs documentation. This is NOT a
    change in behavior for almost all SQL statements except:
     - ALTER TABLE t1 RENAME t2 
     - OPTIMIZE TABLE t1
     - ANALYZE TABLE t1
     - TRUNCATE TABLE t1 --
     until this patch t1 or t2 could be evaluated at the first execution of
     prepared statement. 

     CURRENT_DATABASE() still works OK and is evaluated at every execution
     of prepared statement.

     Note, that in stored routines this is not an issue as the default
     database is the database of the stored procedure and "use" statement
     is prohibited in stored routines.

  This patch makes obsolete the use of check_db_used (it was never used in the
  old code too) and all other places that check for table->db and assign it
  from THD::db if it's NULL, except the parser.

 How this patch was created: THD::{db,db_length} were replaced with a
 LEX_STRING, THD::db. All the places that refer to THD::{db,db_length} were
 manually checked and:
  - if the place uses thd->db by pointer, it was fixed to make a deep copy
  - if a place compared two db pointers, it was fixed to compare them by value
    (via strcmp/my_strcasecmp, whatever was approproate)
 Then this intermediate patch was used to write a smaller patch that does the
 same thing but without a rename.

 TODO in 5.1:
   - remove check_db_used
   - deploy THD::set_db in mysql_change_db

 See also comments to individual files.
2006-06-27 00:47:52 +04:00
konstantin@mysql.com
a04bfd8e2a Merge mysql.com:/opt/local/work/tmp_merge
into  mysql.com:/opt/local/work/mysql-5.1-runtime
2006-06-26 18:49:20 +04:00
konstantin@mysql.com
e20898a507 A fix and a test case for Bug#15217 "Using a SP cursor on a table created
with PREPARE fails with weird error".
More generally, re-executing a stored procedure with a complex SP cursor query
could lead to a crash.

The cause of the problem was that SP cursor queries were not optimized 
properly at first execution: their parse tree belongs to sp_instr_cpush,
not sp_instr_copen, and thus the tree was tagged "EXECUTED" when the
cursor was declared, not when it was opened. This led to loss of optimization
transformations performed at first execution, as sp_instr_copen saw that the
query is already "EXECUTED" and therefore either not ran first-execution 
related blocks or wrongly rolled back the transformations caused by 
first-execution code.
The fix is to update the state of the parsed tree only when the tree is
executed, as opposed to when the instruction containing the tree is executed.
Assignment if i->state is moved to reset_lex_and_exec_core.
2006-06-22 19:29:48 +04:00
lars@mysql.com
5f37fc4a76 Merge mysql.com:/users/lthalmann/bkroot/mysql-5.1-new-rpl
into  mysql.com:/users/lthalmann/bk/MERGE/mysql-5.1-merge
2006-06-16 01:15:19 +02:00
msvensson@neptunus.(none)
2c538f6cde Merge bk-internal:/home/bk/mysql-5.1
into  neptunus.(none):/home/msvensson/mysql/mysql-5.1-new-maint
2006-06-10 20:33:50 +02:00