An error occurred fetching the project authors.
  1. 06 Mar, 2007 2 commits
    • malff/marcsql@weblab.(none)'s avatar
      Manual merge · fedd1ae7
      malff/marcsql@weblab.(none) authored
      fedd1ae7
    • malff/marcsql@weblab.(none)'s avatar
      Bug#8407 (Stored functions/triggers ignore exception handler) · b216d959
      malff/marcsql@weblab.(none) authored
      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.
      b216d959
  2. 22 Jan, 2007 3 commits
  3. 17 Jan, 2007 1 commit
  4. 14 Dec, 2006 1 commit
    • kaa@polly.local's avatar
      Fix for bug #24117 "server crash on a FETCH with a cursor on a table which is... · 4162e009
      kaa@polly.local authored
      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.
      4162e009
  5. 11 Dec, 2006 2 commits
  6. 09 Dec, 2006 1 commit
    • patg@govinda.patg.net's avatar
      WL# 3031 · 98062f56
      patg@govinda.patg.net authored
      Post-commit issues fixed
      * Test results for other tests fixed due to added error #s
      * Memory allocation/free issues found with running with valgrind
      * Fix to mysql-test-run shell script to run federated_server test (installs
      mysql.servers table properly)
      98062f56
  7. 05 Dec, 2006 2 commits
  8. 17 Nov, 2006 1 commit
  9. 15 Nov, 2006 3 commits
    • malff/marcsql@weblab.(none)'s avatar
    • andrey@example.com's avatar
      post-merge fix · 85da10fa
      andrey@example.com authored
      85da10fa
    • malff/marcsql@weblab.(none)'s avatar
      Bug#18239 (Possible to overload internal functions with stored functions) · 6e29099d
      malff/marcsql@weblab.(none) authored
      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.
      6e29099d
  10. 14 Nov, 2006 1 commit
    • andrey@example.com's avatar
      Fix for bug#23760 ROW_COUNT() and store procedure not owrking together · 9299fd67
      andrey@example.com authored
      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
      9299fd67
  11. 23 Oct, 2006 1 commit
  12. 19 Oct, 2006 2 commits
    • malff/marcsql@weblab.(none)'s avatar
      Bug#20028 (Function with select return no data) · ea0998ca
      malff/marcsql@weblab.(none) authored
      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)
      ea0998ca
    • malff/marcsql@weblab.(none)'s avatar
      manual merge · 3312c2a3
      malff/marcsql@weblab.(none) authored
      3312c2a3
  13. 17 Oct, 2006 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#20028 (Function with select return no data) · 1f4edce1
      malff/marcsql@weblab.(none) authored
      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.
      1f4edce1
  14. 09 Oct, 2006 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#21462 (Stored procedures with no arguments require parenthesis) · 6e809b24
      malff/marcsql@weblab.(none) authored
      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.
      6e809b24
  15. 29 Sep, 2006 1 commit
  16. 27 Sep, 2006 2 commits
  17. 18 Sep, 2006 1 commit
  18. 16 Sep, 2006 1 commit
    • igor@rurik.mysql.com's avatar
      Fixed bug #21493: crash for the second execution of a function · d3d3cef8
      igor@rurik.mysql.com authored
      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.)
      d3d3cef8
  19. 12 Sep, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      BUG#21414: SP: Procedure undroppable, to some extent · ed0cb3e4
      kroki/tomash@moonlight.intranet authored
      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.
      ed0cb3e4
  20. 07 Sep, 2006 1 commit
  21. 30 Aug, 2006 1 commit
  22. 24 Aug, 2006 2 commits
  23. 23 Aug, 2006 2 commits
  24. 14 Aug, 2006 1 commit
  25. 10 Aug, 2006 1 commit
  26. 09 Aug, 2006 1 commit
  27. 04 Aug, 2006 1 commit
  28. 03 Aug, 2006 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#8153 (Stored procedure with subquery and continue handler, wrong result) · 21f00113
      malff/marcsql@weblab.(none) authored
      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.
      21f00113
  29. 27 Jul, 2006 1 commit
    • anozdrin/alik@booka.'s avatar
      Fix for BUG#16211: Stored function return type for strings is ignored. · b7f403b5
      anozdrin/alik@booka. authored
      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.
      b7f403b5