An error occurred fetching the project authors.
  1. 13 Nov, 2006 1 commit
  2. 21 Sep, 2006 1 commit
    • dlenev@mockturtle.local's avatar
      Fix for bug#20670 "UPDATE using key and invoking trigger that modifies · 091ed9fb
      dlenev@mockturtle.local authored
      this key does not stop" (version for 5.0 only).
      
      UPDATE statement which WHERE clause used key and which invoked trigger
      that modified field in this key worked indefinetely.
      
      This problem occured because in cases when UPDATE statement was
      executed in update-on-the-fly mode (in which row is updated right
      during evaluation of select for WHERE clause) the new version of
      the row became visible to select representing WHERE clause and was
      updated again and again.
      We already solve this problem for UPDATE statements which does not
      invoke triggers by detecting the fact that we are going to update
      field in key used for scanning and performing update in two steps,
      during the first step we gather information about the rows to be
      updated and then doing actual updates. We also do this for
      MULTI-UPDATE and in its case we even detect situation when such
      fields are updated in triggers (actually we simply assume that
      we always update fields used in key if we have before update
      trigger).
      
      The fix simply extends this check which is done in check_if_key_used()/
      QUICK_SELECT_I::check_if_keys_used() routine/method in such way that
      it also detects cases when field used in key is updated in trigger.
      As nice side-effect we have more precise and thus more optimal
      perfomance-wise check for the MULTI-UPDATE.
      Also check_if_key_used()/QUICK_SELECT_I::check_if_keys_used() were
      renamed to is_key_used()/QUICK_SELECT_I::is_keys_used() in order to
      better reflect that boolean predicate.
      
      Note that this check is implemented in much more elegant way in 5.1 
      091ed9fb
  3. 25 Aug, 2006 1 commit
    • andrey@example.com's avatar
      Fix for bug#21795: SP: sp_head::is_not_allowed_in_function() contains · f115ecf8
      andrey@example.com authored
      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.
      f115ecf8
  4. 24 Aug, 2006 1 commit
  5. 23 Aug, 2006 1 commit
  6. 29 Jun, 2006 1 commit
  7. 28 Jun, 2006 2 commits
    • kroki@mysql.com's avatar
      Bug#10946: Confusing error messeges in the case of duplicate trigger definition · 3e2e20ec
      kroki@mysql.com authored
      It was hard to distinguish case, when one was unable to create trigger
      on the table because trigger with same action time and event already
      existed for this table, from the case, when one tried to create trigger
      with name which was already occupied by some other trigger, since in
      both these cases we emitted ER_TRG_ALREADY_EXISTS error and message.
      Now we emit ER_NOT_SUPPORTED_YET error with appropriate additional
      message in the first case. There is no sense in introducing separate
      error for this situation since we plan to get rid of this limitation
      eventually.
      3e2e20ec
    • jimw@mysql.com's avatar
      Bug #18005: Creating a trigger on mysql.event leads to server crash on scheduler startup · 5d2c0de5
      jimw@mysql.com authored
      Bug #18361: Triggers on mysql.user table cause server crash
      
       Because they do not work, we do not allow creating triggers on tables
       within the 'mysql' schema.
      
       (They may be made to work and re-enabled at some later date, but not
       in 5.0 or 5.1.)
      5d2c0de5
  8. 16 Jun, 2006 1 commit
    • dlenev@mysql.com's avatar
      Fix for bug#13479 "REPLACE activates UPDATE trigger, not the DELETE and · 59d20e26
      dlenev@mysql.com authored
      INSERT triggers".
      
      In cases when REPLACE was internally executed via update and table had
      on update (on delete) triggers defined we exposed the fact that such
      optimization used by callng on update (not calling on delete) triggers.
      Such behavior contradicts our documentation which describes REPLACE as
      INSERT with optional DELETE.
      
      This fix just disables this optimization for tables with on delete triggers.
      The optimization is still applied for tables which have on update but have
      no on delete triggers, we just don't invoke on update triggers in this case
      and thus don't expose information about optimization to user.
      
      Also added test coverage for values returned by ROW_COUNT() function (and
      thus for values returned by mysql_affected_rows()) for various forms of
      INSERT.
      59d20e26
  9. 12 May, 2006 1 commit
  10. 19 Apr, 2006 2 commits
  11. 18 Apr, 2006 1 commit
  12. 12 Apr, 2006 1 commit
    • kroki@mysql.com's avatar
      Bug#16461: connection_id() does not work properly inside trigger · c8e22ff7
      kroki@mysql.com authored
      CONNECTION_ID() was implemented as a constant Item, i.e. an instance of
      Item_static_int_func class holding value computed at creation time.
      Since Items are created on parsing, and trigger statements are parsed
      on table open, the first connection to open a particular table would
      effectively set its own CONNECTION_ID() inside trigger statements for
      that table.
      
      Re-implement CONNECTION_ID() as a class derived from Item_int_func, and
      compute connection_id on every call to fix_fields().
      c8e22ff7
  13. 29 Mar, 2006 1 commit
    • dlenev@mysql.com's avatar
      Proposed fix for bug #17764 "Trigger crashes MyISAM table" · 17785d16
      dlenev@mysql.com authored
      A table with an on insert trigger was reported as crashed when the insert
      was processed with bulk insert mode on (handler::start_bulk_insert).
      The trigger was also selecting from the same table, and that caused
      the "crash".
      The same problem was present when an insert statement, which was processed
      in bulk mode, also used a stored function that was reading the same table.
      
      This fix disables bulk inserts if a statement uses functions or invokes
      triggers. Implementing more granular checks will require much more code and
      therefore can hardly be done in 5.0
      17785d16
  14. 24 Mar, 2006 1 commit
  15. 04 Mar, 2006 1 commit
    • dlenev@mysql.com's avatar
      Fix for bug #17866 "Problem with renaming table with triggers with fully · efe09006
      dlenev@mysql.com authored
      qualified subject table" which was introduced during work on bug #13525
      "Rename table does not keep info of triggers".
      
      The bug was caused by the fact that during reconstruction of CREATE TRIGGER
      statement stored in .TRG file which happened during RENAME TABLE we damaged
      trigger definition in case when it contained fully qualified name of subject
      table (see comment for sql_yacc.yy for more info).
      efe09006
  16. 27 Feb, 2006 1 commit
  17. 24 Feb, 2006 1 commit
  18. 28 Jan, 2006 1 commit
  19. 24 Jan, 2006 1 commit
  20. 05 Jan, 2006 1 commit
    • monty@mysql.com's avatar
      Review fixes of new pushed code · 6e22e29d
      monty@mysql.com authored
      - Fixed tests
      - Optimized new code
      - Fixed some unlikely core dumps
      - Better bug fixes for:
        - #14397 - OPTIMIZE TABLE with an open HANDLER causes a crash
        - #14850 (ERROR 1062 when a quering a view using a Group By on a column that can be null
      6e22e29d
  21. 11 Dec, 2005 1 commit
  22. 22 Nov, 2005 2 commits
    • bell@sanja.is.com.ua's avatar
      7bd691f1
    • bell@sanja.is.com.ua's avatar
      Fix for BUG#13549 "Server crash with nested stored procedures · 2bcd6897
      bell@sanja.is.com.ua authored
      if inner routine has more local variables than outer one, and
      one of its last variables was used as argument to NOT operator".
      
      THD::spcont was non-0 when we were parsing stored routine/trigger
      definition during execution of another stored routine. This confused
      methods of Item_splocal and forced them use wrong runtime context.
      Fix ensures that we always have THD::spcont equal to zero during
      routine/trigger body parsing. This also allows to avoid problems
      with errors which occur during parsing and SQL exception handlers.
      2bcd6897
  23. 17 Nov, 2005 1 commit
  24. 14 Sep, 2005 1 commit
    • dlenev@mysql.com's avatar
      Fix for bug #12704 "Server crashes during trigger execution". · e231ebe5
      dlenev@mysql.com authored
      This bug occurs when some trigger for table used by DML statement is created
      or changed while statement was waiting in lock_tables(). In this situation
      prelocking set which we have calculated becames invalid which can easily lead
      to errors and even in some cases to crashes.
      
      With proposed patch we no longer silently reopen tables in lock_tables(),
      instead caller of lock_tables() becomes responsible for reopening tables and
      recalculation of prelocking set.
      e231ebe5
  25. 02 Sep, 2005 1 commit
    • konstantin@mysql.com's avatar
      Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures". · 38486e83
      konstantin@mysql.com authored
      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).
      38486e83
  26. 18 Aug, 2005 1 commit
  27. 15 Aug, 2005 2 commits
    • monty@mysql.com's avatar
      Fixed typo in error numbers · d0c66bba
      monty@mysql.com authored
      d0c66bba
    • monty@mysql.com's avatar
      Save and clear run context before executing a stored function or trigger and restore it afterwards. · df32f7d6
      monty@mysql.com authored
      This allows us to use statement replication with functions and triggers
      The following things are fixed with this patch:
      - NOW() and automatic timestamps takes the value from the main event for functions and triggers (which allows these to replicate with statement level logging)
      - No side effects for triggers or functions with auto-increment values(), last_insert_id(), rand() or found_rows()
      - Triggers can't return result sets
      
      Fixes bugs:
      #12480: NOW() is not constant in a trigger
      #12481: Using NOW() in a stored function breaks statement based replication
      #12482: Triggers has side effects with auto_increment values
      #11587: trigger causes lost connection error
      df32f7d6
  28. 10 Aug, 2005 1 commit
  29. 09 Aug, 2005 1 commit
  30. 30 Jul, 2005 1 commit
  31. 28 Jul, 2005 1 commit
  32. 19 Jul, 2005 2 commits
  33. 13 Jul, 2005 2 commits
  34. 09 Jul, 2005 1 commit