should fail to create
The problem was that this type of errors was checked during view
creation, which doesn't happen when CREATE VIEW is a statement of
a created stored routine.
The solution is to perform the checks at parse time. The idea of the
fix is that the parser checks if a construction just parsed is allowed
in current circumstances by testing certain flags, and this flags are
reset for VIEWs.
The side effect of this change is that if the user already have
such bogus routines, it will now get a error when trying to do
SHOW CREATE PROCEDURE proc;
(and some other) and when trying to execute such routine he will get
ERROR 1457 (HY000): Failed to load routine test.p5. The table mysql.proc is missing, corrupt, or contains bad data (internal code -6)
However there should be very few such users (if any), and they may
(and should) drop these bogus routines.
erroneous check
Problem: Actually there were two problems in the server code. The check
for SQLCOM_FLUSH in SF/Triggers were not according to the existing
architecture which uses sp_get_flags_for_command() from sp_head.cc .
This function was also missing a check for SQLCOM_FLUSH which has a
problem combined with prelocking. This changeset fixes both of these
deficiencies as well as the erroneous check in
sp_head::is_not_allowed_in_function() which was a copy&paste error.
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
- Add prelocking for stored procedures that uses sp or sf
- Update test result for sp_error(reported as bug#21294)
- Make note about new error message from sp-error(bug#17244)
Under row-based replication, DELETE FROM will now always be
replicated as individual row deletions, while TRUNCATE TABLE will
always be replicated as a statement.
SHOW AUTHORS caused 'Packets out of order' in stored functions:
add the corresponding SQLCOM to sp_get_flags_for_command so that
it'd return sp-related flags for it.
Fix Bug#17403 "Events: packets out of order with show create event"
in the same chaneset.
The name length was checked "the old way", not taking charsets into account,
when creating a stored routine.
Fixing this enforces the real limit (64 characters) again, and no truncation
is possible.
Check if AGGREGATE was given with a stored (non-UDF) function, and return
error in that case.
Also made udf_example/udf_test work again, by adding a missing *_init()
function. (_init() functions required unless --allow_suspicious_udfs is
given to the server, since March 2005 - it seems udf_example wasn't updated
at the time.)
which was fixed by earlier changesets; LOAD INDEX is not allowed in functions.
Also testing CACHE INDEX, while OPTIMIZE and CHECK were covered by existing tests already.
impossible view security".
We should not expose names of tables which are explicitly or implicitly (via
routine or trigger) used by view even if we find that they are missing.
So during building of list of prelocked tables for statement we track which
routines (and therefore tables for these routines) are used from views. We
mark elements of LEX::routines set which correspond to routines used in views
by setting Sroutine_hash_entry::belong_to_view member to point to TABLE_LIST
object for topmost view which uses routine. We propagate this mark to all
routines which are used by this routine and which we add to this set. We also
mark tables used by such routine which we add to the list of tables for
prelocking as belonging to this view.
The crash mentioned in original bug report is already prevented by one
of previous patches (fix for bug #13343 "CREATE|etc TRIGGER|VIEW|USER
don't commit the transaction (inconsistency)"), this patch only improve
error returning.
we changing current db temporarily and restore it when sp is created. however thd->db
in this case becomes empty string rather than NULL and so all checks of thd->db == NULL
will be false. So if after this we'll issue create procedure sp2()... without specifying
db it will succeed and create sp with db=NULL, which causes mysqldto crash on
show procedure status statement.
This patch fixes the problem.
Disallow conflicting use of variables named "password" and "names". If such
a variable is declared, and "SET ... = ..." is used for them, an error is
returned; the user must resolve the conflict by either using `var` (indicating
that the local variable is set) or by renaming the variable.
This is necessary since setting "password" and "names" are treated as special
cases by the parser.
- Added functionality to check errors returned from mysql_next_result
- Exit from mysqltest when and unexpected error occurs.
- The above fixes reveal problems with rpl000009, sp-error and query_cache-
- Fix sp-error by adding an expected error
- Fix rpl000009 by not sending "ok" from mysql_create_db when called with silent flag from load_master_data
- Fix query_cache in separate patch
Second version after review. Allow 'set autocommit' in procedures, but not
functions or triggers. Can return error in run-time (when a function calls
a procedure).
OPTIMIZE TABLE statement is forbidden from usage in stored procedures/functions.
NOTE: OPTIMIZE TABLE statement can be useful in stored procedures. The idea is
that the user/administrator can create a stored procedure for admin
tasks (optimizing, backing up, etc). This procedure can be scheduled to run
automatically (by mean of internal cron (WL#1034)). So, once we can make this
statement work, it is worth doing it.
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
If we are in stored function or trigger we should ensure that we won't change
table that is already used by calling statement (this can damage table or
easily cause infinite loops). Particularly this means that recursive triggers
should be disallowed.
