produce wrong data
By default Item_sp_func::val_str() returns string from it's result_field
internal buffer. When grouping is present Item_copy_string is used to
store SP function result, but it doesn't additionally buffer the result.
When the next record is read, internal buffer is overwritten, due to
this Item_copy_string::val_str() will have wrong data. Thus producing
weird query result.
The Item_func_sp::val_str() now makes a copy of returned value to prevent
occasional corruption.
time per connection
Removed const_string() method from Item_string (it was only used in one
place, in a bad way). Defer possible SP variable, and access data directly
instead, in date_format item.
The idea is to add DEFINER-clause in CREATE PROCEDURE and CREATE FUNCTION
statements. Almost all support of definer in stored routines had been already
done before this patch.
NOTE: this patch changes behaviour of dumping stored routines in mysqldump.
Before this patch, mysqldump did not dump DEFINER-clause for stored routines
and this was documented behaviour. In order to get full information about stored
routines, one should have dumped mysql.proc table. This patch changes this
behaviour, so that DEFINER-clause is dumped.
Since DEFINER-clause is not supported in CREATE PROCEDURE | FUNCTION statements
before this patch, the clause is covered by additional version-specific comments.
The problem was a code generation bug: cpop instructions were not generated
when using ITERATE back to an outer block from a context with a declared
cursor; this would make it push a new cursor without popping in-between,
eventually overrunning the cursor stack with a crash as the result.
Fixed the calculation of how many cursors to pop (in sp_pcontext.cc:
diff_cursors()), and also corrected diff_cursors() and diff_handlers()
to when doing a "leave"; don't include the last context we're leaving
(we are then jumping to the appropriate pop instructions).
Implement table-level TRIGGER privilege to control access to triggers.
Before this path global SUPER privilege was used for this purpose, that
was the big security problem.
In details, before this patch SUPER privilege was required:
- for the user at CREATE TRIGGER time to create a new trigger;
- for the user at DROP TRIGGER time to drop the existing trigger;
- for the definer at trigger activation time to execute the trigger (if the
definer loses SUPER privilege, all its triggers become unavailable);
This patch changes the behaviour in the following way:
- TRIGGER privilege on the subject table for trigger is required:
- for the user at CREATE TRIGGER time to create a new trigger;
- for the user at DROP TRIGGER time to drop the existing trigger;
- for the definer at trigger activation time to execute the trigger
(if the definer loses TRIGGER privilege on the subject table, all its
triggers on this table become unavailable).
- SUPER privilege is still required:
- for the user at CREATE TRIGGER time to explicitly set the trigger
definer to the user other than CURRENT_USER().
When the server works with database of the previous version (w/o TRIGGER
privilege), or if the database is being upgraded from the previous versions,
TRIGGER privilege is granted to whose users, who have CREATE privilege.
After trying multiple inheritance (to messy and hard make it work) and
sublassing jump_if_not (worked, but ugly), decided to on this solution
instead:
Inserting an abstract sp_instr_opt_meta class as parent for all instructions
with destinations makes it possible to handle a continuation pointer for
sp_instr_set_case_expr too.
Note: No special test case; the fix is captured by the changed behaviour of
bug14643_2, and bug14498_4 (formerly disabled), in sp.test.
