An error occurred fetching the project authors.
  1. 26 Nov, 2007 1 commit
  2. 09 Oct, 2007 1 commit
    • davi@virtua-cwbas201-21-158-74.ctb.virtua.com.br's avatar
      Bug#28318 CREATE FUNCTION (UDF) requires a schema · fd3c6b18
      Bug#29816 Syntactically wrong query fails with misleading error message
      
      The core problem is that an SQL-invoked function name can be a <schema
      qualified routine name> that contains no <schema name>, but the mysql
      parser insists that all stored procedures (function, procedures and
      triggers) must have a <schema name>, which is not true for functions.
      This problem is especially visible when trying to create a function
      or when a query contains a syntax error after a function call (in the
      same query), both will fail with a "No database selected" message if
      the session is not attached to a particular schema, but the first
      one should succeed and the second fail with a "syntax error" message.
      
      Part of the fix is to revamp the sp name handling so that a schema
      name may be omitted for functions -- this means that the internal
      function name representation may not have a dot, which represents
      that the function doesn't have a schema name. The other part is
      to place schema checks after the type (function, trigger or procedure)
      of the routine is known.
      fd3c6b18
  3. 25 Jul, 2007 1 commit
  4. 12 Jul, 2007 1 commit
    • kostja@bodhi.(none)'s avatar
      A fix and a test case for Bug#26141 mixing table types in trigger · 5ab4b6f1
      kostja@bodhi.(none) authored
      causes full table lock on innodb table.
      Also fixes Bug#28502 Triggers that update another innodb table 
      will block on X lock unnecessarily (duplciate).
      Code review fixes.
      
      Both bugs' synopses are misleading: InnoDB table is
      not X locked. The statements, however, cannot proceed concurrently, 
      but this happens due to lock conflicts for tables used in triggers,
      not for the InnoDB table. 
      
      If a user had an InnoDB table, and two triggers, AFTER UPDATE and 
      AFTER INSERT, competing for different resources (e.g. two distinct
      MyISAM tables), then these two triggers would not be able to execute
      concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would
      not be able to run concurrently. 
      The problem had other side-effects (see respective bug reports).
      
      This behavior was a consequence of a shortcoming of the pre-locking
      algorithm, which would not distinguish between different DML operations
      (e.g. INSERT and DELETE) and pre-lock all the tables
      that are used by any trigger defined on the subject table.
      
      The idea of the fix is to extend the pre-locking algorithm to keep track,
      for each table, what DML operation it is used for and not
      load triggers that are known to never be fired.
      5ab4b6f1
  5. 04 Jul, 2007 1 commit
    • kostja@bodhi.(none)'s avatar
      A fix and a teset case for Bug#28551 The warning · c3f37e0b
      kostja@bodhi.(none) authored
      'No database selected' is reported when calling stored procedures
      
      Remove the offending warning introduced by the fix for Bug
      25082
      This minimal patch relies on the intrinsic knowledge of the fact that
      mysql_change_db is never called with 'force_switch' set to TRUE
      when such a warning may be needed:
       * every stored routine belongs to a database (unlike, e.g., a 
      user defined function, which does not), so if we're activating the
      database of a stored routine, it can never be NULL.
      Therefore, this branch is never called for activation.
       * if we're restoring the 'old' current database after routine
      execution is complete, we should not issue a warning, since it's OK to 
      call a routine without having previously selected the current database.
      
      TODO: 'force_switch' is an ambiguous flag, since we do not actually
      have to 'force' the switch in case of stored routines at all.
      When we activate the routine's database, we should perform
      all the checks as in case of 'use db', and so we already do (in this
      case 'force_switch' is unused).
      When we load a routine into cache, we should not use mysql_change_db
      at all, since there it's enough to call thd->reset_db(). We
      do it this way for triggers, but code for routines is different (wrongly). 
      
      TODO: bugs are lurking in replication, since it bypasses mysql_change_db
      and calls thd->[re_]set_db to set the current database.
      The latter does not change thd->db_charset, thd->sctx->db_access
      and thd->variables.collation_database (and this may have nasty side
      effects).
      
      These todo items are to be addressed in a separate patch, if at all.
      c3f37e0b
  6. 18 Jun, 2007 1 commit
  7. 16 May, 2007 1 commit
    • msvensson@pilot.blaudden's avatar
      Backport of TIME->MYSQL_TIME / Y2K fixset · a65d12a8
      msvensson@pilot.blaudden authored
         
      Made year 2000 handling more uniform
      Removed year 2000 handling out from calc_days()
      The above removes some bugs in date/datetimes with year between 0 and 200
      Now we get a note when we insert a datetime value into a date column
      For default values to CREATE, don't give errors for warning level NOTE
      Fixed some compiler failures
      Added library ws2_32 for windows compilation (needed if we want to compile with IOCP support)
      Removed duplicate typedef TIME and replaced it with MYSQL_TIME
      
      Better (more complete) fix for: Bug#21103 "DATE column not compared as DATE"
      Fixed properly Bug#18997 "DATE_ADD and DATE_SUB perform year2K autoconversion magic on 4-digit year value"
      Fixed Bug#23093 "Implicit conversion of 9912101 to date does not match cast(9912101 as date)"
       
      a65d12a8
  8. 24 Apr, 2007 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#25411 (trigger code truncated), PART I · fc809c70
      malff/marcsql@weblab.(none) authored
      The issue found with bug 25411 is due to the function skip_rear_comments()
      which damages the source code while implementing a work around.
      The root cause of the problem is in the lexical analyser, which does not
      process special comments properly.
      For special comments like :
      [1] aaa /*!50000 bbb */ ccc
      since 5.0 is a version older that the current code, the parser is in lining
      the content of the special comment, so that the query to process is
      [2] aaa bbb ccc
      However, the text of the query captured when processing a stored procedure,
      stored function or trigger (or event in 5.1), can be after rebuilding it:
      [3] aaa bbb */ ccc
      which is wrong.
      
      To fix bug 25411 properly, the lexical analyser needs to return [2] when
      in lining special comments.
      In order to implement this, some preliminary cleanup is required in the code,
      which is implemented by this patch.
      
      Before this change, the structure named LEX (or st_lex) contains attributes
      that belong to lexical analysis, as well as attributes that represents the
      abstract syntax tree (AST) of a statement.
      Creating a new LEX structure for each statements (which makes sense for the
      AST part) also re-initialized the lexical analysis phase each time, which
      is conceptually wrong.
      
      With this patch, the previous st_lex structure has been split in two:
      - st_lex represents the Abstract Syntax Tree for a statement. The name "lex"
      has not been changed to avoid a bigger impact in the code base.
      - class lex_input_stream represents the internal state of the lexical
        analyser, which by definition should *not* be reinitialized when parsing
        multiple statements from the same input stream.
      
      This change is a pre-requisite for bug 25411, since the implementation of
      lex_input_stream will later improve to deal properly with special comments,
      and this processing can not be done with the current implementation of
      sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer.
      
      This change set alone does not fix bug 25411.
      fc809c70
  9. 27 Mar, 2007 2 commits
    • anozdrin/alik@alik.opbmk's avatar
      Fix for BUG#25082: default database change on trigger · cc83bb07
      anozdrin/alik@alik.opbmk authored
      execution breaks replication.
      
      When a stored routine is executed, we switch current
      database to the database, in which the routine
      has been created. When the stored routine finishes,
      we switch back to the original database.
      
      The problem was that if the original database does not
      exist (anymore) after routine execution, we raised an error.
      
      The fix is to report a warning, and switch to the NULL database.
      cc83bb07
    • iggy@recycle.(none)'s avatar
      Bug#23491 MySQLDump prefix function call in a view by database name · bbc38df0
      iggy@recycle.(none) authored
      - mysqldump executes a SHOW CREATE VIEW statement to generate the text
      that it outputs.  When the function name is retrieved it's database 
      name is unconditionally prepended.  This change causes the function's 
      database name to be prepended only when it was used to define the 
      function.
      bbc38df0
  10. 23 Dec, 2006 1 commit
  11. 15 Dec, 2006 1 commit
  12. 30 Nov, 2006 1 commit
  13. 28 Nov, 2006 1 commit
  14. 01 Nov, 2006 1 commit
  15. 03 Oct, 2006 1 commit
    • cmiller@zippy.cornsilk.net's avatar
      Bug #14262: SP: DROP PROCEDURE|VIEW (maybe more) write to binlog too late \ · 5512100c
      cmiller@zippy.cornsilk.net authored
      	(race cond)
      
      It was possible for one thread to interrupt a Data Definition Language 
      statement and thereby get messages to the binlog out of order.  Consider:
      
      Connection 1: Drop Foo x
      Connection 2: Create or replace Foo x
      Connection 2: Log "Create or replace Foo x"
      Connection 1: Log "Drop Foo x"
      
      Local end would have Foo x, but the replicated slaves would not.
      
      The fix for this is to wrap all DDL and logging of a kind in the same mutex.  
      Since we already use mutexes for the various parts of altering the server, 
      this only entails moving the logging events down close to the action, inside 
      the mutex protection.
      5512100c
  16. 27 Sep, 2006 2 commits
  17. 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
  18. 07 Sep, 2006 1 commit
  19. 24 Aug, 2006 1 commit
  20. 27 Jul, 2006 2 commits
    • anozdrin/alik@booka.'s avatar
      Fix for BUG#20438: CREATE statements for views, stored routines and triggers · 2d082d86
      anozdrin/alik@booka. authored
      can be not replicable.
      
      Now CREATE statements for writing in the binlog are created as follows:
        - the beginning of the statement is re-created;
        - the rest of the statement is copied from the original query.
      
      The problem appears when there is a version-specific comment (produced by
      mysqldump), started in the re-created part of the statement and closed in the
      copied part -- there is closing comment-parenthesis, but there is no opening
      one.
      
      The proper fix could be to re-create original statement, but we can not
      implement it in 5.0. So, for 5.0 the fix is just to cut closing
      comment-parenthesis. This technique is also used for SHOW CREATE PROCEDURE
      statement (so we are able to reuse existing code).
      2d082d86
    • 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
  21. 19 Jul, 2006 1 commit
    • kostja@bodhi.local's avatar
      A fix and a test case for Bug#21002 "Derived table not selecting from a · f22a4ce1
      kostja@bodhi.local authored
      "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. 
      f22a4ce1
  22. 26 Jun, 2006 1 commit
    • konstantin@mysql.com's avatar
      A fix and a test case for · 117b76a5
      konstantin@mysql.com authored
       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.
      117b76a5
  23. 04 May, 2006 1 commit
  24. 21 Apr, 2006 1 commit
  25. 18 Apr, 2006 1 commit
  26. 28 Mar, 2006 1 commit
  27. 10 Mar, 2006 1 commit
  28. 02 Mar, 2006 1 commit
    • anozdrin@mysql.com's avatar
      Implementation of WL#2897: Complete definer support in the stored routines. · fbb59203
      anozdrin@mysql.com authored
      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.
      fbb59203
  29. 22 Feb, 2006 1 commit
  30. 16 Feb, 2006 1 commit
  31. 02 Feb, 2006 1 commit
  32. 26 Jan, 2006 1 commit
  33. 10 Jan, 2006 1 commit
  34. 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
  35. 07 Dec, 2005 2 commits
    • anozdrin@mysql.com's avatar
      Patch for WL#2894: Make stored routine variables work · 0ff8f60b
      anozdrin@mysql.com authored
      according to the standard.
      
      The idea is to use Field-classes to implement stored routines
      variables. Also, we should provide facade to Item-hierarchy
      by Item_field class (it is necessary, since SRVs take part
      in expressions).
      
      The patch fixes the following bugs:
        - BUG#8702: Stored Procedures: No Error/Warning shown for inappropriate data 
          type matching; 
       
        - BUG#8768: Functions: For any unsigned data type, -ve values can be passed 
          and returned; 
       
        - BUG#8769: Functions: For Int datatypes, out of range values can be passed 
          and returned; 
       
        - BUG#9078: STORED PROCDURE: Decimal digits are not displayed when we use 
          DECIMAL datatype; 
       
        - BUG#9572: Stored procedures: variable type declarations ignored; 
       
        - BUG#12903: upper function does not work inside a function; 
       
        - BUG#13705: parameters to stored procedures are not verified; 
       
        - BUG#13808: ENUM type stored procedure parameter accepts non-enumerated
          data; 
       
        - BUG#13909: Varchar Stored Procedure Parameter always BINARY string (ignores 
          CHARACTER SET); 
       
        - BUG#14161: Stored procedure cannot retrieve bigint unsigned;
      
        - BUG#14188: BINARY variables have no 0x00 padding;
      
        - BUG#15148: Stored procedure variables accept non-scalar values;
      0ff8f60b
    • dlenev@mysql.com's avatar
      Fix for bug #11555 "Stored procedures: current SP tables locking make · 06b895c0
      dlenev@mysql.com authored
      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.
      06b895c0
  36. 06 Dec, 2005 1 commit