1. 25 May, 2007 2 commits
    • unknown's avatar
      Code review comments · 4c6e754d
      unknown authored
      
      sql/sql_lex.cc:
        Fixed parenthese typo, found during code review
      4c6e754d
    • unknown's avatar
      Bug#27876 (SF with cyrillic variable name fails during execution (regression)) · a200ec51
      unknown authored
      The root cause of this bug is related to the function skip_rear_comments,
      in sql_lex.cc
      
      Recent code changes in skip_rear_comments changed the prototype from
      "const uchar*" to "const char*", which had an unforseen impact on this test:
        (endp[-1] < ' ')
      With unsigned characters, this code filters bytes of value [0x00 - 0x20]
      With *signed* characters, this also filters bytes of value [0x80 - 0xFF].
      
      This caused the regression reported, considering cyrillic characters in the
      parameter name to be whitespace, and truncated.
      Note that the regression is present both in 5.0 and 5.1.
      
      With this fix:
      - [0x80 - 0xFF] bytes are no longer considered whitespace.
      This alone fixes the regression.
      
      In addition, filtering [0x00 - 0x20] was found bogus and abusive,
      so that the code now filters uses my_isspace when looking for whitespace.
      
      Note that this fix is only addressing the regression affecting UTF-8
      in general, but does not address a more fundamental problem with
      skip_rear_comments: parsing a string *backwards*, starting at end[-1],
      is not safe with multi-bytes characters, so that end[-1] can confuse the
      last byte of a multi-byte characters with a characters to filter out.
      
      The only known impact of this remaining issue affects objects that have to
      meet all the conditions below:
      
      - the object is a FUNCTION / PROCEDURE / TRIGGER / EVENT / VIEW
      - the body consist of only *1* instruction, and does *not* contain a
        BEGIN-END block
      - the instruction ends, lexically, with <ident> <whitespace>* ';'?
        For example, "select <ident>;" or "return <ident>;"
      - The last character of <ident> is a multi-byte character
      - the last byte of this character is ';' '*', '/' or whitespace
      
      In this case, the body of the object will be truncated after parsing,
      and stored in an invalid format.
      
      This last issue has not been fixed in this patch, since the real fix
      will be implemented by Bug 25411 (trigger code truncated), which is caused
      by the very same code.
      The real problem is that the function skip_rear_comments is only a
      work-around, and should be removed entirely: see the proposed patch for
      bug 25411 for details.
      
      
      sql/sp_head.cc:
        In skip_rear_comments,
        Filter out only whitespace, not other (non ascii or control) valid characters
      sql/sql_lex.cc:
        In skip_rear_comments,
        Filter out only whitespace, not other (non ascii or control) valid characters
      sql/sql_lex.h:
        In skip_rear_comments,
        Filter out only whitespace, not other (non ascii or control) valid characters
      sql/sql_view.cc:
        In skip_rear_comments,
        Filter out only whitespace, not other (non ascii or control) valid characters
      tests/mysql_client_test.c:
        Bug#27876 (SF with cyrillic variable name fails during execution (regression))
      a200ec51
  2. 24 May, 2007 1 commit
  3. 23 May, 2007 4 commits
    • unknown's avatar
      5.0 version of fix for: · e8c35f16
      unknown authored
       Bug #23667 "CREATE TABLE LIKE is not isolated from alteration
                   by other connections"
       Bug #18950 "CREATE TABLE LIKE does not obtain LOCK_open"
      As well as:
       Bug #25578 "CREATE TABLE LIKE does not require any privileges
                   on source table".
      
      The first and the second bugs resulted in various errors and wrong
      binary log order when one tried to execute concurrently CREATE TABLE LIKE
      statement and DDL statements on source table or DML/DDL statements on its
      target table.
      
      The problem was caused by incomplete protection/table-locking against
      concurrent statements implemented in mysql_create_like_table() routine.
      We solve it by simply implementing such protection in proper way (see
      comment for sql_table.cc for details).
      
      The third bug allowed user who didn't have any privileges on table create
      its copy and therefore circumvent privilege check for SHOW CREATE TABLE.
      
      This patch solves this problem by adding privilege check, which was missing.
      
      Finally it also removes some duplicated code from mysql_create_like_table().
      
      Note that, altough tests covering concurrency-related aspects of CREATE TABLE
      LIKE behaviour will only be introduced in 5.1, they were run manually for
      this patch as well.
      
      
      mysql-test/r/grant2.result:
        Added test for bug#25578 "CREATE TABLE LIKE does not require any privileges
        on source table".
      mysql-test/t/grant2.test:
        Added test for bug#25578 "CREATE TABLE LIKE does not require any privileges
        on source table".
      sql/handler.h:
        Introduced new flag for HA_CREATE_INFO::options in order to be able to
        distinguish CREATE TABLE ... LIKE from other types of CREATE TABLE.
      sql/mysql_priv.h:
        mysql_create_like_table() now takes source table name not as a
        Table_ident object but as regular table list element.
      sql/sql_parse.cc:
        CREATE TABLE ... LIKE implementation now uses statement's table list
        for storing information about the source table. We also use flag
        in LEX::create_info.options for distinguishing it from other types
        of CREATE TABLE.
        Finally CREATE TABLE ... LIKE now requires the same privileges on
        the source tables as SHOW CREATE TABLE. Moved this privilege check
        to check_show_create_table_access() function.
      sql/sql_table.cc:
        mysql_create_like_table():
         - Provided proper protection from concurrent statements.
           This is achieved by keeping name-lock on the source table and holding
           LOCK_open mutex during whole operation. This gives protection against
           concurrent DDL on source table. Also holding this mutex makes copying
           of .frm file, call to ha_create_table() and binlogging atomic against
           concurrent DML and DDL operations on target table.
         - Get rid of duplicated code related to source database/table name
           handling. All these operations are already done in
           st_select_lex::add_table_to_list(), so we achieve the same effect
           by including source table into the statement's table list.
      sql/sql_yacc.yy:
        Now we use special flag in LEX::create_info::options for distinguishing
        CREATE TABLE ... LIKE from other types of CREATE TABLE and store name
        of source table as regular element in statement's table list.
      e8c35f16
    • unknown's avatar
      Merge mysql.com:/home/svoj/devel/mysql/merge/mysql-4.1-engines · 3862944a
      unknown authored
      into  mysql.com:/home/svoj/devel/mysql/merge/mysql-5.0-engines
      
      3862944a
    • unknown's avatar
      Merge mysql.com:/home/svoj/devel/bk/mysql-5.0 · 07796719
      unknown authored
      into  mysql.com:/home/svoj/devel/mysql/merge/mysql-5.0-engines
      
      07796719
    • unknown's avatar
      Merge mysql.com:/home/svoj/devel/bk/mysql-4.1 · d6de9411
      unknown authored
      into  mysql.com:/home/svoj/devel/mysql/merge/mysql-4.1-engines
      
      d6de9411
  4. 22 May, 2007 3 commits
  5. 21 May, 2007 6 commits
  6. 19 May, 2007 2 commits
    • unknown's avatar
      Merge pilot.blaudden:/home/msvensson/mysql/bug28401/my50-bug28401 · ee27eef7
      unknown authored
      into  pilot.blaudden:/home/msvensson/mysql/mysql-5.0-maint
      
      ee27eef7
    • unknown's avatar
      Bug #28401 mysql_upgrade Failed with STRICT_ALL_TABLES, ANSI_QUOTES and NO_ZERO_DATE · 8942e322
      unknown authored
       - The SQL commands used by mysql_upgrade are written to be run
          with sql_mode set to '' - thus the scripts should change sql_mode
          for the session to make sure the SQL is legal.
      
      
      mysql-test/r/mysql_upgrade.result:
        Update test result
      mysql-test/t/mysql_upgrade.test:
        The SQL commands used by mysql_upgrade are written to be run
        with sql_mode set to '' - thus the scripts should change sql_mode
        for the session to make sure the SQL is legal.
      scripts/mysql_system_tables_fix.sql:
        Set sql_mode to '' before running the SQL commands
        to fix system tables - backport from 5.1
      8942e322
  7. 18 May, 2007 22 commits