An error occurred fetching the project authors.
  1. 16 Nov, 2006 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#22684 (BENCHMARK, ENCODE, DECODE and FORMAT are not real functions) · ccfbd686
      malff/marcsql@weblab.(none) authored
      Before this change, the functions BENCHMARK, ENCODE, DECODE and FORMAT could
      only accept a constant for some parameters.
      
      After this change, this restriction has been removed. An implication is that
      these functions can also be used in prepared statements.
      
      The change consist of changing the following classes:
      - Item_func_benchmark
      - Item_func_encode
      - Item_func_decode
      - Item_func_format
      to:
      - only accept Item* in the constructor,
      - and evaluate arguments during calls to val_xxx()
      which fits the general design of all the other functions.
      
      The 'TODO' items identified in item_create.cc during the work done for
      Bug 21114 are addressed by this fix, as a natural consequence of aligning
      the design.
      
      In the 'func_str' test, a single very long test line involving an explain
      extended select with many functions has been rewritten into multiple
      separate tests, to improve maintainability.
      The result of explain extended select decode(encode(...)) has changed,
      since the encode and decode functions now print all their parameters.
      ccfbd686
  2. 02 Nov, 2006 2 commits
  3. 19 Oct, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      BUG#21856: Prepared Statements: crash if bad create · 00b2fc6a
      kroki/tomash@moonlight.intranet authored
      When statement to be prepared contained CREATE PROCEDURE, CREATE FUNCTION
      or CREATE TRIGGER statements with a syntax error in it, the preparation
      would fail with syntax error message, but the memory could be corrupted.
      
      The problem occurred because we switch memroot when parse stored
      routine or trigger definitions, and on parse error we restored the
      original memroot only after performing some memory operations.  In more
      detail:
       - prepared statement would activate its own memory root to parse
         the definition of the stored procedure.
       - SP would reset this memory root with its own memory root to
         parse SP statements
       - a syntax error would happen
       - prepared statement would restore the original memory root
       - stored procedure would restore what it thinks was the original
         memory root, but actually was the statement memory root.
      That led to double free - in destruction of the statement and in
      a next call to mysql_parse().
      
      The solution is to restore memroot right after the failed parsing.
      00b2fc6a
  4. 17 Oct, 2006 1 commit
  5. 12 Oct, 2006 1 commit
  6. 11 Oct, 2006 2 commits
  7. 10 Oct, 2006 3 commits
  8. 27 Sep, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      BUG#21081: SELECT inside stored procedure returns wrong results · 0bdc597b
      kroki/tomash@moonlight.intranet authored
      Re-execution of a parametrized prepared statement or a stored routine
      with a SELECT that use LEFT JOIN with second table having only one row
      could yield incorrect result.
      
      The problem appeared only for left joins with second table having only
      one row (aka const table) and equation conditions in ON or WHERE clauses
      that depend on the argument passed.  Once the condition was false for
      second const table, a NULL row was created for it, and any field involved
      got NULL-value flag, which then was never reset.
      
      The cause of the problem was that Item_field::null_value could be set
      without being reset for re-execution.  The solution is to reset
      Item_field::null_value in Item_field::cleanup().
      0bdc597b
  9. 19 Sep, 2006 1 commit
  10. 16 Sep, 2006 1 commit
    • igor@rurik.mysql.com's avatar
      Fixed bug #22085: Crash on the execution of a prepared · dd3b8e4f
      igor@rurik.mysql.com authored
      statement that uses an aggregating IN subquery with 
      HAVING clause.
      A wrong order of the call of split_sum_func2 for the HAVING
      clause of the subquery and the transformation for the 
      subquery resulted in the creation of a andor structure
      that could not be restored at an execution of the prepared
      statement.
      dd3b8e4f
  11. 24 Aug, 2006 1 commit
  12. 23 Aug, 2006 1 commit
    • andrey@example.com's avatar
      Fix for bug #20665 All commands supported in Stored Procedures · 9c8c1817
      andrey@example.com authored
      should work in Prepared Statements. Post-review changeset.
      
      Problem: There are some commands which are avaiable to be executed in SP
               but cannot be prepared. This patch fixes this and makes it possible
               prepare these statements.
      
      Changes: The commands later are made available in PS. RESET has been forbidden
               in SF/Trigger.
      
      Solution: All current server commands where checked and those missing (see later)
                we added. Tests for all of the commands with repeated executions were
                added - testing with SP, SF and PS.
      
      SHOW BINLOG EVENTS
      SHOW (MASTER | SLAVE) STATUS
      SHOW (MASTER | BINARY) LOGS
      SHOW (PROCEDURE | FUNCTION) CODE (parsable only in debug builds)
      SHOW CREATE (PROCEDURE | FUNCTION | EVENT | TABLE | VIEW)
      SHOW (AUTHORS | CONTRIBUTORS | WARNINGS | ERRORS)
      CHANGE MASTER
      RESET (MASTER | SLAVE | QUERY CACHE)
      SLAVE (START | STOP)
      CHECKSUM (TABLE | TABLES)
      INSTALL PLUGIN
      UNINSTALL PLUGIN
      CACHE INDEX
      LOAD INDEX INTO CACHE
      GRANT
      REVOKE
      KILL
      (CREATE | RENAME | DROP) DATABASE
      (CREATE | RENAME | DROP) USER
      FLUSH (TABLE | TABLES | TABLES WITH READ LOCK | HOSTS | PRIVILEGES |
             LOGS | STATUS | MASTER | SLAVE | DES_KEY_FILE | USER_RESOURCES)
      9c8c1817
  13. 02 Aug, 2006 1 commit
  14. 14 Jul, 2006 1 commit
  15. 11 Jul, 2006 1 commit
  16. 06 Jul, 2006 1 commit
    • konstantin@bodhi.netgear's avatar
      A fix and a test case for Bug#19399 "res 'Lost Connection' when · 8e735d2c
      konstantin@bodhi.netgear authored
      dropping/creating tables".
      
      The bug could lead to a crash when multi-delete statements were
      prepared and used with temporary tables.
      
      The bug was caused by lack of clean-up of multi-delete tables before
      re-execution of a prepared statement. In a statement like
      DELETE t1 FROM t1, t2 WHERE ... the first table list (t1) is
      moved to lex->auxilliary_table_list and excluded from lex->query_tables
      or select_lex->tables. Thus it was unaccessible to reinit_stmt_before_use
      and not cleaned up before re-execution of a prepared statement. 
      8e735d2c
  17. 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
  18. 14 Jun, 2006 1 commit
    • bar@mysql.com's avatar
      Bug#8663 cant use bgint unsigned as input to cast · a481a352
      bar@mysql.com authored
      Problem: cast to unsigned limited result to 
      max signed bigint 9223372036854775808,
      instead of max unsigned bigint 18446744073709551615.
      
      Fix: don't use args[0]->val_int() when casting from
      a floating point number, use val() instead, with range checkings,
      special to unsigned data type.
      
      item_func.cc:
        Special handling of cast from REAL_RESULT
        to unsigned int: we cannot execute args[0]->val_int()
        because it cuts max allowed value to LONGLONG_INT,
        instead of ULONGLONG_INT required.
      count_distinct3.test:
        Getting rid of "Data truncated; out of range ..." warnings.
      cast.test, cast.result:
        Adding test case.
      ps.result:
        Fixing that cast from 6570515219.6535 
        to unsigned didn't round to 6570515220,
        and returned 6570515219 instead.
      a481a352
  19. 06 Jun, 2006 1 commit
    • monty@mysql.com's avatar
      Re-apply missing changeset, orignally pushed by elliot · e50412ef
      monty@mysql.com authored
      Add define YASSL_PREFIX when compiling yassl
      
      Import patch from yaSSL
      - avoid allocating memory for each call to 'EVP_md5' and 
        'EVP_des_ede3_cbc' which were not released until server was stopped
      - Those functions are used from the SQL function 'des_encrypt' and
        'des_decrypt'.
      
      Add new define YASSL_PREFIX beforee including ssl.h to activate inclusion of prefix_*.h files
      
      Bug#20022 mysql-test-run can't be run with secure connections turned on for all testcases
      - Part 1, fixes rpl- and federated-tests where connection is made to 127.0.0.1
      
      - Include prefix files that renames all public functions in yaSSLs
        OpenSSL API to ya<function_name>. They will otherwise conflict
        with OpenSSL functions if loaded by an application that uses OpenSSL
        as well as libmysqlclient with yaSSL support.
      
      Bug#18235: assertion/crash when windows mysqld is ended with ctrl-c
        
      Two threads both try a shutdown sequence which creates a race to the
      de-init/free of certain resources.
        
      This exists in similar form in the client as 17926: "mysql.exe crashes
      when ctrl-c is pressed in windows."
      
      Update after merge to 5.0
      
      BUG#18669: Session COM_STATISTICS breaks mysqladmin status.
      Changed COM_STATISTICS to display the global status, instead of thead status, for slow queries and table opens.
      
      - In function 'handle_grant_struct' when searching the memory structures for an 
        entry to modify, convert all entries here host.hostname is NULL to "" and compare that 
        with the host passed in argument "user_from".
      - A user created with hostname "" is stored in "mysql.user" table as host="" but when loaded into 
        memory it'll be stored as host.hostname NULL. Specifiying "" as hostname means
        that "any host" can connect. Thus is's correct to turn on allow_all_hosts
        when such a user is found. 
      - Review and fix other places where host.hostname may be NULL.
      
      BUG#19394 OPT_INNODB_THREAD_CONCURRENCY duplicated
      Removed duplication (not a user-visible change)
      e50412ef
  20. 29 May, 2006 1 commit
  21. 25 Apr, 2006 1 commit
  22. 12 Apr, 2006 1 commit
  23. 07 Apr, 2006 2 commits
    • konstantin@mysql.com's avatar
      A fix and a test case for Bug#16365 "Prepared Statements: DoS with · 51899331
      konstantin@mysql.com authored
      too many open statements". The patch adds a new global variable
      @@max_prepared_stmt_count. This variable limits the total number
      of prepared statements in the server. The default value of
      @@max_prepared_stmt_count is 16382. 16382 small statements
      (a select against 3 tables with GROUP, ORDER and LIMIT) consume 
      100MB of RAM. Once this limit has been reached, the server will 
      refuse to prepare a new statement and return ER_UNKNOWN_ERROR 
      (unfortunately, we can't add new errors to 4.1 without breaking 5.0). The limit is changeable after startup
      and can accept any value from 0 to 1 million. In case
      the new value of the limit is less than the current
      statement count, no new statements can be added, while the old
      still can be used. Additionally, the current count of prepared 
      statements is now available through a global read-only variable 
      @@prepared_stmt_count.
      51899331
    • konstantin@mysql.com's avatar
      A fix and a test case for Bug#16248 "WHERE (col1,col2) IN ((?,?)) · 15b59156
      konstantin@mysql.com authored
      gives wrong results". Implement previously missing 
      Item_row::cleanup. The bug is not repeatable in 5.0, probably 
      due to a coincidence: the problem is present in 5.0 as well.
      15b59156
  24. 28 Mar, 2006 1 commit
  25. 27 Feb, 2006 1 commit
  26. 23 Feb, 2006 1 commit
  27. 21 Feb, 2006 1 commit
  28. 01 Feb, 2006 1 commit
    • anozdrin@mysql.com's avatar
      Fix for BUG#9412: Triggers: should have trigger privilege. · 0a1f7e92
      anozdrin@mysql.com authored
      Implement table-level TRIGGER privilege to control access to triggers.
      Before this path global SUPER privilege was used for this purpose, that
      was the big security problem.
      
      In details, before this patch SUPER privilege was required:
        - for the user at CREATE TRIGGER time to create a new trigger;
        - for the user at DROP TRIGGER time to drop the existing trigger;
        - for the definer at trigger activation time to execute the trigger (if the
          definer loses SUPER privilege, all its triggers become unavailable);
      
      This patch changes the behaviour in the following way:
        - TRIGGER privilege on the subject table for trigger is required:
          - for the user at CREATE TRIGGER time to create a new trigger;
          - for the user at DROP TRIGGER time to drop the existing trigger;
          - for the definer at trigger activation time to execute the trigger
            (if the definer loses TRIGGER privilege on the subject table, all its
            triggers on this table become unavailable).
        - SUPER privilege is still required:
          - for the user at CREATE TRIGGER time to explicitly set the trigger
            definer to the user other than CURRENT_USER().
      
      When the server works with database of the previous version (w/o TRIGGER
      privilege), or if the database is being upgraded from the previous versions,
      TRIGGER privilege is granted to whose users, who have CREATE privilege.
      0a1f7e92
  29. 16 Jan, 2006 1 commit
  30. 14 Jan, 2006 2 commits
  31. 10 Jan, 2006 1 commit
  32. 26 Dec, 2005 1 commit
  33. 28 Nov, 2005 1 commit
  34. 25 Nov, 2005 1 commit