An error occurred fetching the project authors.
  1. 12 Jan, 2006 1 commit
  2. 08 Dec, 2005 1 commit
    • konstantin@mysql.com's avatar
      A fix and a test case for Bug#15441 "Running SP causes Server · bbf3a593
      konstantin@mysql.com authored
      to Crash": the bug was that due to non-standard name
      resolution precedence in stored procedures (See Bug#5967)
      a stored procedure variable took precedence over a table column
      when the arguments for VALUES() function were resolved.
      The implementation of VALUES() function was not designed to work
      with Item_splocal and crashed.
      VALUES() function is non-standard. It can refer to, and
      is meaningful for, table columns only. The patch disables SP 
      variables as possible arguments of VALUES() function.
      bbf3a593
  3. 07 Dec, 2005 1 commit
    • 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
  4. 03 Dec, 2005 1 commit
  5. 02 Dec, 2005 2 commits
  6. 28 Nov, 2005 1 commit
  7. 25 Nov, 2005 1 commit
  8. 23 Nov, 2005 1 commit
  9. 22 Nov, 2005 2 commits
  10. 18 Nov, 2005 1 commit
  11. 17 Nov, 2005 1 commit
    • pem@mysql.com's avatar
      Background: · c518a240
      pem@mysql.com authored
      Since long, the compiled code of stored routines has been printed in the trace file
      when starting mysqld with the "--debug" flag. (At creation time only, and only in
      debug builds of course.) This has been helpful when debugging stored procedure
      execution, but it's a bit awkward to use. Also, the printing of some of the
      instructions is a bit terse, in particular for sp_instr_stmt where only the command
      code was printed.
      
      This improves the printout of several of the instructions, and adds the debugging-
      only commands "show procedure code <name>" and "show function code <name>".
      (In non-debug builds they are not available.)
      c518a240
  12. 16 Nov, 2005 1 commit
    • bell@sanja.is.com.ua's avatar
      Issuing error about presence of commit/rollback statements in stored functions... · a60a6b0f
      bell@sanja.is.com.ua authored
      Issuing error about presence of commit/rollback statements in stored functions and triggers added to SP parsing procedure (BUG#13627)
      
      The crash mentioned in original bug report is already prevented by one
      of previous patches (fix for bug #13343 "CREATE|etc TRIGGER|VIEW|USER
      don't commit the transaction (inconsistency)"), this patch only improve
      error returning.
      a60a6b0f
  13. 10 Nov, 2005 1 commit
  14. 09 Nov, 2005 1 commit
  15. 01 Nov, 2005 1 commit
  16. 28 Oct, 2005 1 commit
  17. 25 Oct, 2005 2 commits
  18. 24 Oct, 2005 1 commit
  19. 21 Oct, 2005 2 commits
    • bar@mysql.com's avatar
      Bug#13233 · a167ddc6
      bar@mysql.com authored
        select distinct char(column) fails with utf8
      ctype_utf8.result, ctype_utf8.test:
        Adding test case
      sql_yacc.yy:
        Adding new syntax.
      item_strfunc.h:
        Fixing wrong max_length calculation.
        Also, adding CHAR(x USING charset),
        for easier migrating from 4.1 to 5.0,
        according to Monty's suggestion.
      a167ddc6
    • andrey@lmy004.'s avatar
      fix for bug #12595 (ESCAPE must be exactly 1 character long) · 991b6f14
      andrey@lmy004. authored
      ESCAPE has length of 1 if specified and sql_mode is NO_BACKSLASH_ESCAPES
      or has length of 0 or 1 in every other situation.
      (approved patch applied on a up-to-date tree re-commit) 
      991b6f14
  20. 15 Oct, 2005 2 commits
  21. 13 Oct, 2005 1 commit
    • bar@mysql.com's avatar
      ctype_utf8.result, ctype_utf8.test: · 7c81d7fc
      bar@mysql.com authored
        New syntax: CHAR(x USING charset)
        Adding test case.
      sql_yacc.yy:
        New syntax: CHAR(x USING charset)
        Adding new parser rule.
      item_strfunc.h:
        New syntax: CHAR(x USING charset)
        Adding a new constructor.
      7c81d7fc
  22. 12 Oct, 2005 1 commit
    • grog@mysql.com's avatar
      sql_yacc.yy: · c248a36e
      grog@mysql.com authored
        Bug #10308: Parse 'purge master logs' with subselect correctly.
      subselect.test:
        Bug #10308: Test for 'purge master logs' with subselect.
      subselect.result:
        Bug #10308: Test result for 'purge master logs' with subselect.
      c248a36e
  23. 11 Oct, 2005 1 commit
    • pem@mysql.com's avatar
      Fixed BUG#13510: Setting password local variable changes current password · 2456c0c6
      pem@mysql.com authored
        Disallow conflicting use of variables named "password" and "names". If such
        a variable is declared, and "SET ... = ..." is used for them, an error is
        returned; the user must resolve the conflict by either using `var` (indicating
        that the local variable is set) or by renaming the variable.
        This is necessary since setting "password" and "names" are treated as special
        cases by the parser.
      2456c0c6
  24. 22 Sep, 2005 1 commit
  25. 20 Sep, 2005 2 commits
  26. 19 Sep, 2005 1 commit
  27. 15 Sep, 2005 1 commit
  28. 14 Sep, 2005 3 commits
  29. 13 Sep, 2005 3 commits
  30. 10 Sep, 2005 1 commit
    • timour@mysql.com's avatar
      Fix for BUG#12943. · 7d24bdac
      timour@mysql.com authored
      The problem was that in the first production in rule 'join_table', that
      processes simple cross joins, the parser was processing the second join operand
      before the first one due to unspecified priorities of JOINs. As a result in the
      case of cross joins the parser constructed a tree with incorrect nesting:
      the expression "t1 join t2 join t3 on some_cond" was interpreted as
      "t1 join (t2 join t3 on some_cond)" instead of
      "(t1 join t2) join t3 on some_cond".
      Because of this incorrect nesting the method make_join_on_context picked an
      incorrect table as the first table of the name resolution context.
      
      The solution assignes correct priorities to the related production.
      7d24bdac