An error occurred fetching the project authors.
  1. 05 Dec, 2006 1 commit
  2. 15 Nov, 2006 2 commits
    • malff/marcsql@weblab.(none)'s avatar
    • 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
  3. 23 Oct, 2006 1 commit
  4. 19 Oct, 2006 1 commit
    • 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
  5. 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
  6. 29 Sep, 2006 1 commit
  7. 27 Sep, 2006 2 commits
  8. 18 Sep, 2006 1 commit
  9. 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
  10. 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
  11. 30 Aug, 2006 1 commit
  12. 24 Aug, 2006 2 commits
  13. 23 Aug, 2006 2 commits
  14. 14 Aug, 2006 1 commit
  15. 10 Aug, 2006 1 commit
  16. 09 Aug, 2006 1 commit
  17. 04 Aug, 2006 1 commit
  18. 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
  19. 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
  20. 26 Jul, 2006 1 commit
  21. 25 Jul, 2006 1 commit
    • evgen@moonbone.local's avatar
      Fixed bug#19862: Sort with filesort by function evaluates function twice · 4ee2e07c
      evgen@moonbone.local authored
      When there is no index defined filesort is used to sort the result of a
      query. If there is a function in the select list and the result set should be
      ordered by it's value then this function will be evaluated twice. First time to
      get the value of the sort key and second time to send its value to a user.
      This happens because filesort when sorts a table remembers only values of its
      fields but not values of functions.
      All functions are affected. But taking into account that SP and UDF functions
      can be both expensive and non-deterministic a temporary table should be used 
      to store their results and then sort it to avoid twice SP evaluation and to 
      get a correct result.
      
      If an expression referenced in an ORDER clause contains a SP or UDF 
      function, force the use of a temporary table.
      
      A new Item_processor function called func_type_checker_processor is added
      to check whether the expression contains a function of a particular type.
      4ee2e07c
  22. 21 Jul, 2006 1 commit
  23. 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
  24. 17 Jul, 2006 1 commit
  25. 14 Jul, 2006 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #19714. · f6080640
      igor@olga.mysql.com authored
      DESCRIBE returned the type BIGINT for a column of a view if the column
      was specified by an expression over values of the type INT.
          
      E.g. for the view defined as follows:
        CREATE VIEW v1 SELECT COALESCE(f1,f2) FROM t1
      DESCRIBE returned type BIGINT for the only column of the view if f1,f2 are
      columns of the INT type.
      At the same time DESCRIBE returned type INT for the only column of the table
      defined by the statement:
        CREATE TABLE t2 SELECT COALESCE(f1,f2) FROM t1.
          
      This inconsistency was removed by the patch.
      
      Now the code chooses between INT/BIGINT depending on the
      precision of the aggregated column type.
       
      Thus both DESCRIBE commands above returns type INT for v1 and t2.
       
      f6080640
  26. 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
  27. 22 Jun, 2006 1 commit
    • konstantin@mysql.com's avatar
      A fix and a test case for Bug#15217 "Using a SP cursor on a table created · e20898a5
      konstantin@mysql.com authored
       with PREPARE fails with weird error".
      More generally, re-executing a stored procedure with a complex SP cursor query
      could lead to a crash.
      
      The cause of the problem was that SP cursor queries were not optimized 
      properly at first execution: their parse tree belongs to sp_instr_cpush,
      not sp_instr_copen, and thus the tree was tagged "EXECUTED" when the
      cursor was declared, not when it was opened. This led to loss of optimization
      transformations performed at first execution, as sp_instr_copen saw that the
      query is already "EXECUTED" and therefore either not ran first-execution 
      related blocks or wrongly rolled back the transformations caused by 
      first-execution code.
      The fix is to update the state of the parsed tree only when the tree is
      executed, as opposed to when the instruction containing the tree is executed.
      Assignment if i->state is moved to reset_lex_and_exec_core.
      e20898a5
  28. 01 Jun, 2006 1 commit
  29. 18 May, 2006 3 commits
  30. 10 May, 2006 1 commit
  31. 09 May, 2006 1 commit
    • dlenev@mysql.com's avatar
      Fix for bugs#12472/#15137 'CREATE TABLE ... SELECT ... which explicitly · 589daad1
      dlenev@mysql.com authored
      or implicitly uses stored function gives "Table not locked" error'
      
      CREATE TABLE ... SELECT ... statement which was explicitly or implicitly
      (through view) using stored function gave "Table not locked" error.
      
      The actual bug resides in the current locking scheme of CREATE TABLE SELECT
      code, which first opens and locks tables of the SELECT statement itself,
      and then, having SELECT tables locked, creates the .FRM, opens the .FRM and
      acquires lock on it. This scheme opens a possibility for a deadlock, which
      was present and ignored since version 3.23 or earlier. This scheme also
      conflicts with the invariant of the prelocking algorithm -- no table can
      be open and locked while there are tables locked in prelocked mode.
      
      The patch makes an exception for this invariant when doing CREATE TABLE ...
      SELECT, thus extending the possibility of a deadlock to the prelocked mode.
      We can't supply a better fix in 5.0.
      589daad1
  32. 21 Apr, 2006 1 commit
  33. 18 Apr, 2006 1 commit
  34. 11 Apr, 2006 1 commit