An error occurred fetching the project authors.
  1. 03 Sep, 2007 1 commit
  2. 29 Jul, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #30120. · 1eb20fc0
      gshchepa/uchum@gleb.loc authored
      SP with local variables with non-ASCII names crashed the server.
      
      The server replaces SP local variable names with NAME_CONST calls
      when putting statements into the binary log. It used UTF8-encoded
      item names as variable names for the replacement inside NAME_CONST
      calls. However, statement string may be encoded by any
      known character set by the SET NAMES statement.
      The server used byte length of UTF8-encoded names to increment
      the position in the query string that led to array index overrun.
      1eb20fc0
  3. 28 Jul, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #29834. · ff5d7202
      gshchepa/uchum@gleb.loc authored
      Using view columns by their names during an execution of
      a prepared SELECT statement or a SELECT statement inside
      a SP caused a memory leak.
      ff5d7202
  4. 21 Jul, 2007 1 commit
  5. 19 Jul, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #29338. · 73b2848f
      gshchepa/uchum@gleb.loc authored
      Optimization of queries with DETERMINISTIC functions in the
      WHERE clause was not effective: sequential scan was always
      used.
      Now a SF with the DETERMINISTIC flags is treated as constant
      when it's arguments are constants (or a SF doesn't has arguments).
      73b2848f
  6. 05 Jul, 2007 1 commit
    • kostja@bodhi.(none)'s avatar
      A fix and a test case for Bug#29050 Creation of a legal stored procedure · a7b05cb7
      kostja@bodhi.(none) authored
      fails if a database is not selected prior.
      
      The problem manifested itself when a user tried to
      create a routine that had non-fully-qualified identifiers in its bodies
      and there was no current database selected.
      
      This is a regression introduced by the fix for Bug 19022:
      
      The patch for Bug 19022 changes the code to always produce a warning
      if we can't resolve the current database in the parser. 
      In this case this was not necessary, since even though the produced
      parsed tree was incorrect, we never re-use sphead
      that was obtained at first parsing of CREATE PROCEDURE.
      The sphead that is anyhow used is always obtained through db_load_routine,
      and there we change the current database to sphead->m_db before
      calling yyparse.
      
      The idea of the fix is to resolve the current database directly using 
      lex->sphead->m_db member when parsing a stored routine body, when
      such is present.
      
      This patch removes the need to reset the current database
      when loading a trigger or routine definition into SP cache.
      The redundant code will be removed in 5.1.
      a7b05cb7
  7. 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
  8. 27 Jun, 2007 1 commit
  9. 01 Jun, 2007 1 commit
  10. 29 May, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #28605: SHOW CREATE VIEW with views using stored_procedures no · a6ebd634
      gkodinov/kgeorge@magare.gmz authored
       longer showing SP names.
      SHOW CREATE VIEW uses Item::print() methods to reconstruct the 
      statement text from the parse tree.
      The print() method for stored procedure calls needs allocate 
      space to print the function's quoted name.
      It was incorrectly calculating the length of the buffer needed 
      (was too short).
      Fixed to reflect the actual space needed.
      a6ebd634
  11. 27 Apr, 2007 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#21513 (SP having body starting with quoted label rendered unusable) · 012f841f
      malff/marcsql@weblab.(none) authored
      Before this fix, the parser would sometime change where a token starts by
      altering Lex_input_string::tok_start, which later confused the code in
      sql_yacc.yy that needs to capture the source code of a SQL statement,
      like to represent the body of a stored procedure.
      
      This line of code in sql_lex.cc :
      
      case MY_LEX_USER_VARIABLE_DELIMITER:
        lip->tok_start= lip->ptr; // Skip first `
      
      would <skip the first back quote> ... and cause the bug reported.
      
      In general, the responsibility of sql_lex.cc is to *find* where token are
      in the SQL text, but is *not* to make up fake or incomplete tokens.
      With a quoted label like `my_label`, the token starts on the first quote.
      Extracting the token value should not change that (it did).
      
      With this fix, the lexical analysis has been cleaned up to not change
      lip->tok_start (in the case found for this bug).
      
      The functions get_token() and get_quoted_token() now have an extra
      parameters, used when some characters from the beginning of the token need
      to be skipped when extracting a token value, like when extracting 'AB' from
      '0xAB', for example, for a HEX_NUM token.
      
      This exposed a bad assumption in Item_hex_string and Item_bin_string,
      which has been fixed:
      
      The assumption was that the string given, 'AB', was in fact preceded in
      memory by '0x', which might be false (it can be preceded by "x'" and
      followed by "'" -- or not be preceded by valid memory at all)
      
      If a name is needed for Item_hex_string or Item_bin_string, the name is
      taken from the original and true source code ('0xAB'), and assigned in
      the select_item rule, instead of relying on assumptions related to how
      memory is used.
      012f841f
  12. 25 Apr, 2007 1 commit
  13. 12 Apr, 2007 1 commit
  14. 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
    • thek@kpdesk.mysql.com's avatar
      Corrected error in test case: · 1381b26e
      thek@kpdesk.mysql.com authored
      - 1.84e+15 converted to unsigned bigint should be
        18400000000000000000 < 18446744073709551615.
      - The test will still fail on windows, and is extracted
        into a new bug report.
      1381b26e
  15. 22 Mar, 2007 1 commit
  16. 16 Mar, 2007 1 commit
    • Kristofer.Pettersson@naruto.'s avatar
      Bug#20777 Function w BIGINT UNSIGNED shows diff. behaviour with and without --ps-protocol · 05bef788
      Kristofer.Pettersson@naruto. authored
      - Stored procedures returning unsinged values returns signed values if
        text protocol is used. The reason is that the stored proceedure item
        Item_func_sp wasn't initializing the member variables properly based
        on the information contained in the associated result field.
      - The patch is to upon field-item association, ::fix_fields, initialize
        the member variables in appropriate order.
      - Field type of an Item_func_sp was hard coded to MYSQL_TYPE_VARCHAR.
        This is changed to return the type of the actual result field.
      - Member function name sp_result_field was refactored to the more 
        appropriate init_result_field.
      - Member function name find_and_check_access was refactored to 
        sp_check_access.
      05bef788
  17. 14 Mar, 2007 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#26503 (Illegal SQL exception handler code causes the server to crash) · bef323b1
      malff/marcsql@weblab.(none) authored
      Before this fix, the parser would accept illegal code in SQL exceptions
      handlers, that later causes the runtime to crash when executing the code,
      due to memory violations in the exception handler stack.
      
      The root cause of the problem is instructions within an exception handler
      that jumps to code located outside of the handler. This is illegal according
      to the SQL 2003 standard, since labels located outside the handler are not
      supposed to be visible (they are "out of scope"), so any instruction that
      jumps to these labels, like ITERATE or LEAVE, should not parse.
      
      The section of the standard that is relevant for this is :
        SQL:2003 SQL/PSM (ISO/IEC 9075-4:2003)
        section 13.1 <compound statement>,
        syntax rule 4
      <quote>
        The scope of the <beginning label> is CS excluding every <SQL schema
        statement> contained in CS and excluding every
        <local handler declaration list> contained in CS. <beginning label> shall
        not be equivalent to any other <beginning label>s within that scope.
      </quote>
      
      With this fix, the C++ class sp_pcontext, which represent the "parsing
      context" tree (a.k.a symbol table) of a stored procedure, has been changed
      as follows:
      - constructors have been cleaned up, so that only building a root node for
      the tree is public; building nodes inside a tree is not public.
      - a new member, m_label_scope, indicates if a given syntactic context
      belongs to a DECLARE HANDLER block,
      - label resolution, in the method find_label(), has been changed to
      implement the restriction of scope regarding labels used in a compound
      statement.
      
      The actions in the parser, when parsing the body of a SQL exception handler,
      have been changed as follows:
      - the implementation of an exception handler (DECLARE HANDLER) now creates
      explicitly a new sp_pcontext, to isolate the code inside the handler from
      the containing compound statement context.
      - registering exception handlers as a result occurs in the parent context,
      see the rule sp_hcond_element
      - the code in sp_hcond_list has been cleaned up, to avoid code duplication
      
      In addition, the flags IN_SIMPLE_CASE and IN_HANDLER, declared in sp_head.h
      have been removed, since they are unused and broken by design (as seen with
      Bug 19194 (Right recursion in parser for CASE causes excessive stack usage,
      limitation), representing a stack in a single flag is not possible.
      
      Tests in sp-error have been added to show that illegal constructs are now
      rejected.
      
      Tests in sp have been added for code coverage, to show that ITERATE or LEAVE
      statements are legal when jumping to a label in scope, inside the body of
      an exception handler.
      bef323b1
  18. 07 Mar, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#25373: Stored functions wasn't compared correctly which leads to a wrong · b81b814c
      evgen@moonbone.local authored
      result.
      
      For built-in functions like sqrt() function names are hard-coded and can be
      compared by pointer. But this isn't the case for a used-defined stored
      functions - names there are dynamical and should be compared as strings.
      
      Now the Item_func::eq() function employs my_strcasecmp() function to compare
      used-defined stored functions names.
      b81b814c
  19. 06 Mar, 2007 1 commit
    • 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
  20. 19 Feb, 2007 1 commit
    • kaa@polly.local's avatar
      Bug#18743: Several test cases fails if "classic" configuration in 5.0 · 315819fe
      kaa@polly.local authored
      The problem happened because those tests were using "cp932" and "ucs2" without checking whether these character sets are available. This fix moves test parts to make character set specific parts be tested only if they are:
      - some parts were moved to "ctype_ucs.test" and "ctype_cp932.test"
      - some parts were moved to the newly added tests "innodb-ucs2.test", "mysqlbinglog-cp932.test" and "sp-ucs2.test"
      315819fe
  21. 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
  22. 11 Dec, 2006 1 commit
  23. 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
  24. 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
  25. 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
  26. 04 Oct, 2006 1 commit
  27. 29 Sep, 2006 1 commit
  28. 28 Sep, 2006 1 commit
  29. 27 Sep, 2006 1 commit
  30. 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
  31. 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
  32. 07 Sep, 2006 1 commit
  33. 24 Aug, 2006 2 commits
  34. 23 Aug, 2006 2 commits
  35. 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
  36. 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
  37. 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