An error occurred fetching the project authors.
  1. 10 Apr, 2009 1 commit
    • Chad MILLER's avatar
      Bug#39559: dump of stored procedures / functions with C-style \ · aa449c10
      Chad MILLER authored
      	comment can't be read back
      
      A change to the lexer in 5.1 caused slash-asterisk-bang-version
      sections to be terminated early if there exists a slash-asterisk-
      style comment inside it.  Nesting comments is usually illegal,
      but we rely on versioned comment blocks in mysqldump, and the
      contents of those sections must be allowed to have comments.
      
      The problem was that when encountering open-comment tokens and
      consuming -or- passing through the contents, the "in_comment"
      state at the end was clobbered with the not-in-a-comment value,
      regardless of whether we were in a comment before this or not.  
      
      So, """/*!VER one /* two */ three */""" would lose its in-comment
      state between "two" and "three".  Save the echo and in-comment
      state, and restore it at the end of the comment if we consume a 
      comment.
      aa449c10
  2. 03 Apr, 2009 1 commit
    • Davi Arnaut's avatar
      Bug#43230: SELECT ... FOR UPDATE can hang with FLUSH TABLES WITH READ LOCK indefinitely · aebaf079
      Davi Arnaut authored
      The problem is that a SELECT .. FOR UPDATE statement might open
      a table and later wait for a impeding global read lock without
      noticing whether it is holding a table that is being waited upon
      the the flush phase of the process that took the global read
      lock.
      
      The same problem also affected the following statements:
      
      LOCK TABLES .. WRITE
      UPDATE .. SET (update and multi-table update)
      TRUNCATE TABLE ..
      LOAD DATA ..
      
      The solution is to make the above statements wait for a impending
      global read lock before opening the tables. If there is no
      impending global read lock, the statement raises a temporary
      protection against global read locks and progresses smoothly
      towards completion.
      
      Important notice: the patch does not try to address all possible
      cases, only those which are common and can be fixed unintrusively
      enough for 5.0.
      aebaf079
  3. 05 Mar, 2009 1 commit
    • Kristofer Pettersson's avatar
      Bug#39843 DELETE requires write access to table in subquery in where clause · 16347772
      Kristofer Pettersson authored
      An unnecessarily restrictive lock were taken on sub-SELECTs during DELETE.
      
      During parsing, a global structure is reused for sub-SELECTs and the attribute
      keeping track of lock options were not reset properly.
      This patch introduces a new attribute to keep track on the syntactical lock
      option elements found in a sub-SELECT and then sets the lock options accordingly.
      
      Now the sub-SELECTs will try to acquire a READ lock if possible
      instead of a WRITE lock as inherited from the outer DELETE statement.
      16347772
  4. 10 Feb, 2009 1 commit
  5. 16 Dec, 2008 1 commit
  6. 10 Nov, 2008 1 commit
  7. 15 Oct, 2008 1 commit
    • Davi Arnaut's avatar
      Bug#37075: offset of limit clause might be truncated on 32-bits server w/o big tables · 4ab10baa
      Davi Arnaut authored
      The problem is that the offset argument of the limit clause
      might be truncated on a 32-bits server built without big
      tables support. The truncation was happening because the
      original 64-bits long argument was being cast to a 32-bits
      (ha_rows) offset counter.
      
      The solution is to check if the conversing resulted in value
      truncation and if so, the offset is set to the maximum possible
      value that can fit on the type.
      4ab10baa
  8. 07 Oct, 2008 1 commit
    • Gleb Shchepa's avatar
      Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while · e219979e
      Gleb Shchepa authored
                ``FLUSH TABLES WITH READ LOCK''
      
      Concurrent execution of 1) multitable update with a
      NATURAL/USING join and 2) a such query as "FLUSH TABLES
      WITH READ LOCK" or "ALTER TABLE" of updating table led
      to a server crash.
      
      
      The mysql_multi_update_prepare() function call is optimized
      to lock updating tables only, so it postpones locking to
      the last, and if locking fails, it does cleanup of modified
      syntax structures and repeats a query analysis.  However,
      that cleanup procedure was incomplete for NATURAL/USING join
      syntax data: 1) some Field_item items pointed into freed
      table structures, and 2) the TABLE_LIST::join_columns fields
      was not reset.
      
      Major change:
        short-living Field *Natural_join_column::table_field has
        been replaced with long-living Item*.
      e219979e
  9. 18 Sep, 2008 1 commit
    • Gleb Shchepa's avatar
      Bug#26020: User-Defined Variables are not consistent with · db1d38c9
      Gleb Shchepa authored
                 columns data types
      
      The "SELECT @lastId, @lastId := Id FROM t" query returns
      different result sets depending on the type of the Id column
      (INT or BIGINT).
      
      Note: this fix doesn't cover the case when a select query
      references an user variable and stored function that
      updates a value of that variable, in this case a result
      is indeterminate.
      
      
      The server uses incorrect assumption about a constantness of
      an user variable value as a select list item: 
      
      The server caches a last query number where that variable
      was changed and compares this number with a current query
      number. If these numbers are different, the server guesses,
      that the variable is not updating in the current query, so
      a respective select list item is a constant. However, in some
      common cases the server updates cached query number too late.
      
      
      The server has been modified to memorize user variable
      assignments during the parse phase to take them into account
      on the next (query preparation) phase independently of the
      order of user variable references/assignments in a select
      item list.
      db1d38c9
  10. 14 Jul, 2008 1 commit
    • Marc Alff's avatar
      Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on · 0816ee6d
      Marc Alff authored
      build)
      
      The crash was caused by freeing the internal parser stack during the parser
      execution.
      This occured only for complex stored procedures, after reallocating the parser
      stack using my_yyoverflow(), with the following C call stack:
      - MYSQLparse()
      - any rule calling sp_head::restore_lex()
      - lex_end()
      - x_free(lex->yacc_yyss), xfree(lex->yacc_yyvs)
      
      The root cause is the implementation of stored procedures, which breaks the
      assumption from 4.1 that there is only one LEX structure per parser call.
      
      The solution is to separate the LEX structure into:
      - attributes that represent a statement (the current LEX structure),
      - attributes that relate to the syntax parser itself (Yacc_state),
      so that parsing multiple statements in stored programs can create multiple
      LEX structures while not changing the unique Yacc_state.
      
      Now, Yacc_state and the existing Lex_input_stream are aggregated into
      Parser_state, a structure that represent the complete state of the (Lexical +
      Syntax) parser.
      0816ee6d
  11. 07 Jul, 2008 1 commit
    • Marc Alff's avatar
      Bug#26030 (Parsing fails for stored routine w/multi-statement execution · f3ff1aeb
      Marc Alff authored
      enabled)
      
      Before this fix, the lexer and parser would treat the ';' character as a
      different token (either ';' or END_OF_INPUT), based on convoluted logic,
      which failed in simple cases where a stored procedure is implemented as a
      single statement, and used in a multi query.
      
      With this fix:
      - the character ';' is always parsed as a ';' token in the lexer,
      - parsing multi queries is implemented in the parser, in the 'query:' rules,
      - the value of thd->client_capabilities, which is the capabilities
        negotiated between the client and the server during bootstrap,
        is immutable and not arbitrarily modified during parsing (which was the
        root cause of the bug)
      f3ff1aeb
  12. 27 Mar, 2008 1 commit
    • evgen@moonbone.local's avatar
      Bug#27219: Aggregate functions in ORDER BY. · 21c6145a
      evgen@moonbone.local authored
      Mixing aggregate functions and non-grouping columns is not allowed in the
      ONLY_FULL_GROUP_BY mode. However in some cases the error wasn't thrown because
      of insufficient check.
      
      In order to check more thoroughly the new algorithm employs a list of outer
      fields used in a sum function and a SELECT_LEX::full_group_by_flag.
      Each non-outer field checked to find out whether it's aggregated or not and
      the current select is marked accordingly.
      All outer fields that are used under an aggregate function are added to the
      Item_sum::outer_fields list and later checked by the Item_sum::check_sum_func
      function.
      21c6145a
  13. 22 Feb, 2008 1 commit
    • anozdrin/alik@quad.'s avatar
      Fix for Bug#30217: Views: changes in metadata behaviour · 340906f4
      anozdrin/alik@quad. authored
      between 5.0 and 5.1.
        
      The problem was that in the patch for Bug#11986 it was decided
      to store original query in UTF8 encoding for the INFORMATION_SCHEMA.
      This approach however turned out to be quite difficult to implement
      properly. The main problem is to preserve the same IS-output after
      dump/restore.
        
      So, the fix is to rollback to the previous functionality, but also
      to fix it to support multi-character-set-queries properly. The idea
      is to generate INFORMATION_SCHEMA-query from the item-tree after
      parsing view declaration. The IS-query should:
        - be completely in UTF8;
        - not contain character set introducers.
        
      For more information, see WL4052.
      340906f4
  14. 05 Nov, 2007 1 commit
    • istruewing@stella.local's avatar
      Bug#31210 - INSERT DELAYED crashes server when used on · 3eaf82a1
      istruewing@stella.local authored
                  partitioned table
      
      Trying INSERT DELAYED on a partitioned table, that has not been
      used right before, crashes the server. When a table is used for
      select or update, it is kept open for some time. This period I
      mean with "right before".
      
      Information about partitioning of a table is stored in form of
      a string in the .frm file. Parsing of this string requires a
      correctly set up lexical analyzer (lex). The partitioning code
      uses a new temporary instance of a lex. But it does still refer
      to the previously active lex. The delayd insert thread does not
      initialize its lex though...
      
      Added initialization for thd->lex before open table in the delayed
      thread and at all other places where it is necessary to call
      lex_start() if all tables would be partitioned and need to parse
      the .frm file.
      3eaf82a1
  15. 09 Oct, 2007 1 commit
  16. 19 Sep, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #30639: limit offset,rowcount wraps when rowcount >= 2^32 in windows · c2abf960
      gkodinov/kgeorge@magare.gmz authored
       The parser uses ulonglong to store the LIMIT number. This number
       then is stored into a variable of type ha_rows. ha_rows is either
       4 or 8 byte depending on the BIG_TABLES define from config.h
       So an overflow may occur (and LIMIT becomes zero) while storing an
       ulonglong value in ha_rows.
       Fixed by :
        1. Using the maximum possible value for ha_rows on overflow
        2. Defining BIG_TABLES for the windows builds (to match the others) 
      c2abf960
  17. 30 Aug, 2007 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#28779 (mysql_query() allows execution of statements with unbalanced · 4792ed42
      malff/marcsql@weblab.(none) authored
      comments)
      
      This change set is for 5.1 (manually merged)
      
      Before this fix, the server would accept queries that contained comments,
      even when the comments were not properly closed with a '*' '/' marker.
      
      For example,
        select 1 /* + 2 <EOF>
      would be accepted as
        select 1 /* + 2 */ <EOF>
      and executed as
        select 1
      
      With this fix, the server now rejects queries with unclosed comments
      as syntax errors.
      Both regular comments ('/' '*') and special comments ('/' '*' '!') must be
      closed with '*' '/' to be parsed correctly.
      4792ed42
  18. 29 Aug, 2007 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#28779 (mysql_query() allows execution of statements with unbalanced · 6f72d990
      malff/marcsql@weblab.(none) authored
      comments)
      
      Before this fix, the server would accept queries that contained comments,
      even when the comments were not properly closed with a '*' '/' marker.
      
      For example,
        select 1 /* + 2 <EOF>
      would be accepted as
        select 1 /* + 2 */ <EOF>
      and executed as
        select 1
      
      With this fix, the server now rejects queries with unclosed comments
      as syntax errors.
      Both regular comments ('/' '*') and special comments ('/' '*' '!') must be
      closed with '*' '/' to be parsed correctly.
      6f72d990
  19. 23 Aug, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #30396. · 4a7fdf86
      gshchepa/uchum@gleb.loc authored
      Recommit to 5.1.22.
      The bug caused memory corruption for some queries with top OR level
      in the WHERE condition if they contained equality predicates and 
      other sargable predicates in disjunctive parts of the condition.
      
      The corruption happened because the upper bound of the memory
      allocated for KEY_FIELD and SARGABLE_PARAM internal structures
      containing info about potential lookup keys was calculated incorrectly
      in some cases. In particular it was calculated incorrectly when the
      WHERE condition was an OR formula with disjuncts being AND formulas
      including equalities and other sargable predicates.
      4a7fdf86
  20. 22 Aug, 2007 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#30333 (Performance, expressions lists in the parser) · 81114a72
      malff/marcsql@weblab.(none) authored
      Before this patch, the parser would execute:
      - Select->expr_list.push_front()
      - Select->expr_list.pop()
      when parsing expressions lists, in the following rules:
      - udf_expr_list
      - expr_list
      - ident_list
      
      This is unnecessary, and introduces overhead due to the memory allocations
      performed with Select->expr_list
      
      With this patch, this code has been removed.
      The list being parsed is maintained in the parser stack instead.
      
      Also, 'udf_expr_list' has been renamed 'opt_udf_expr_list', since this
      production can be empty.
      81114a72
  21. 16 Aug, 2007 1 commit
  22. 15 Aug, 2007 2 commits
    • igor@olga.mysql.com's avatar
      Fixed bug #30396. · d790ec42
      igor@olga.mysql.com authored
      The bug caused memory corruption for some queries with top OR level
      in the WHERE condition if they contained equality predicates and 
      other sargable predicates in disjunctive parts of the condition.
      
      The corruption happened because the upper bound of the memory
      allocated for KEY_FIELD and SARGABLE_PARAM internal structures
      containing info about potential lookup keys was calculated incorrectly
      in some cases. In particular it was calculated incorrectly when the
      WHERE condition was an OR formula with disjuncts being AND formulas
      including equalities and other sargable predicates.
      d790ec42
    • kostja@bodhi.(none)'s avatar
      Fix doxygen warnings. · 91fe15bb
      kostja@bodhi.(none) authored
      91fe15bb
  23. 13 Aug, 2007 1 commit
    • monty@mysql.com/nosik.monty.fi's avatar
      Fixed a lot of compiler warnings and errors detected by Forte C++ on Solaris · e53a73e2
      monty@mysql.com/nosik.monty.fi authored
      Faster thr_alarm()
      Added 'Opened_files' status variable to track calls to my_open()
      Don't give warnings when running mysql_install_db
      Added option --source-install to mysql_install_db
      
      I had to do the following renames() as used polymorphism didn't work with Forte compiler on 64 bit systems
      index_read()      -> index_read_map()
      index_read_idx()  -> index_read_idx_map()
      index_read_last() -> index_read_last_map()
      e53a73e2
  24. 03 Aug, 2007 1 commit
    • bar@mysql.com/bar.myoffice.izhnet.ru's avatar
      Bug#28875 Conversion between ASCII and LATIN1 charsets does not function · 4eebfd09
      bar@mysql.com/bar.myoffice.izhnet.ru authored
      (Regression, caused by a patch for the bug 22646).
      Problem: when result type of date_format() was changed from
      binary string to character string, mixing date_format()
      with a ascii column in CONCAT() stopped to work.
      Fix:
      - adding "repertoire" flag into DTCollation class,
      to mark items which can return only pure ASCII strings.
      - allow character set conversion from pure ASCII to other character sets.
      4eebfd09
  25. 29 Jul, 2007 2 commits
  26. 27 Jul, 2007 1 commit
    • thek@adventure.(none)'s avatar
      Bug #29929 LOCK TABLES does not pre-lock tables used in triggers of the locked tables · 889b4ebc
      thek@adventure.(none) authored
      When a table was explicitly locked with LOCK TABLES no associated
      tables from any related trigger on the subject table were locked.
      As a result of this the user could experience unexpected locking
      behavior and statement failures similar to "failed: 1100: Table'xx'
      was not locked with LOCK TABLES".
      
      This patch fixes this problem by making sure triggers are
      pre-loaded on any statement if the subject table was explicitly
      locked with LOCK TABLES.
      889b4ebc
  27. 23 Jul, 2007 1 commit
  28. 20 Jul, 2007 1 commit
  29. 16 Jul, 2007 1 commit
  30. 12 Jul, 2007 1 commit
    • kostja@bodhi.(none)'s avatar
      A fix and a test case for Bug#26141 mixing table types in trigger · 5ab4b6f1
      kostja@bodhi.(none) authored
      causes full table lock on innodb table.
      Also fixes Bug#28502 Triggers that update another innodb table 
      will block on X lock unnecessarily (duplciate).
      Code review fixes.
      
      Both bugs' synopses are misleading: InnoDB table is
      not X locked. The statements, however, cannot proceed concurrently, 
      but this happens due to lock conflicts for tables used in triggers,
      not for the InnoDB table. 
      
      If a user had an InnoDB table, and two triggers, AFTER UPDATE and 
      AFTER INSERT, competing for different resources (e.g. two distinct
      MyISAM tables), then these two triggers would not be able to execute
      concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would
      not be able to run concurrently. 
      The problem had other side-effects (see respective bug reports).
      
      This behavior was a consequence of a shortcoming of the pre-locking
      algorithm, which would not distinguish between different DML operations
      (e.g. INSERT and DELETE) and pre-lock all the tables
      that are used by any trigger defined on the subject table.
      
      The idea of the fix is to extend the pre-locking algorithm to keep track,
      for each table, what DML operation it is used for and not
      load triggers that are known to never be fired.
      5ab4b6f1
  31. 06 Jul, 2007 1 commit
    • kostja@bodhi.(none)'s avatar
      Remove typedef st_table_list TABLE_LIST and always use name 'TABLE_LIST'. · a33bc2c2
      kostja@bodhi.(none) authored
      The need arose when working on Bug 26141, where it became
      necessary to replace TABLE_LIST with its forward declaration in a few
      headers, and this involved a lot of s/TABLE_LIST/st_table_list/.
      Although other workarounds exist, this patch is in line
      with our general strategy of moving away from typedef-ed names.
      Sometime in future we might also rename TABLE_LIST to follow the
      coding style, but this is a huge change.
      a33bc2c2
  32. 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
  33. 29 Jun, 2007 2 commits
    • anozdrin/alik@ibm.'s avatar
      Fix typo. · e79410da
      anozdrin/alik@ibm. authored
      e79410da
    • anozdrin/alik@ibm.'s avatar
      Folow up on the CS patch: · bceff6f1
      anozdrin/alik@ibm. authored
      1. Fix ddl_i18n_koi8r, ddl_i18n_utf8: explicitly specify character-sets
      directory for mysqldump;
      2. Fix crash in mysqldump if collation is not found;
      3. Use proper way to compare character set names.
      bceff6f1
  34. 28 Jun, 2007 1 commit
    • anozdrin/alik@ibm.'s avatar
      Patch for the following bugs: · 9fae9ef6
      anozdrin/alik@ibm. authored
        - BUG#11986: Stored routines and triggers can fail if the code
          has a non-ascii symbol
        - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
        - BUG#19443: INFORMATION_SCHEMA does not support charsets properly
        - BUG#21249: Character set of SP-var can be ignored
        - BUG#25212: Character set of string constant is ignored (stored routines)
        - BUG#25221: Character set of string constant is ignored (triggers)
      
      There were a few general problems that caused these bugs:
      1. Character set information of the original (definition) query for views,
         triggers, stored routines and events was lost.
      2. mysqldump output query in client character set, which can be
         inappropriate to encode definition-query.
      3. INFORMATION_SCHEMA used strings with mixed encodings to display object
         definition;
      
      1. No query-definition-character set.
      
      In order to compile query into execution code, some extra data (such as
      environment variables or the database character set) is used. The problem
      here was that this context was not preserved. So, on the next load it can
      differ from the original one, thus the result will be different.
      
      The context contains the following data:
        - client character set;
        - connection collation (character set and collation);
        - collation of the owner database;
      
      The fix is to store this context and use it each time we parse (compile)
      and execute the object (stored routine, trigger, ...).
      
      2. Wrong mysqldump-output.
      
      The original query can contain several encodings (by means of character set
      introducers). The problem here was that we tried to convert original query
      to the mysqldump-client character set.
      
      Moreover, we stored queries in different character sets for different
      objects (views, for one, used UTF8, triggers used original character set).
      
      The solution is
        - to store definition queries in the original character set;
        - to change SHOW CREATE statement to output definition query in the
          binary character set (i.e. without any conversion);
        - introduce SHOW CREATE TRIGGER statement;
        - to dump special statements to switch the context to the original one
          before dumping and restore it afterwards.
      
      Note, in order to preserve the database collation at the creation time,
      additional ALTER DATABASE might be used (to temporary switch the database
      collation back to the original value). In this case, ALTER DATABASE
      privilege will be required. This is a backward-incompatible change.
      
      3. INFORMATION_SCHEMA showed non-UTF8 strings
      
      The fix is to generate UTF8-query during the parsing, store it in the object
      and show it in the INFORMATION_SCHEMA.
      
      Basically, the idea is to create a copy of the original query convert it to
      UTF8. Character set introducers are removed and all text literals are
      converted to UTF8.
      
      This UTF8 query is intended to provide user-readable output. It must not be
      used to recreate the object.  Specialized SHOW CREATE statements should be
      used for this.
      
      The reason for this limitation is the following: the original query can
      contain symbols from several character sets (by means of character set
      introducers).
      
      Example:
      
        - original query:
          CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
      
        - UTF8 query (for INFORMATION_SCHEMA):
          CREATE VIEW v1 AS SELECT 'Hello' AS c1;
      9fae9ef6
  35. 12 Jun, 2007 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#25411 (trigger code truncated), PART II · a508260b
      malff/marcsql@weblab.(none) authored
      Bug 28127 (Some valid identifiers names are not parsed correctly)
      Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
      
      This patch is the second part of a major cleanup, required to fix
      Bug 25411 (trigger code truncated).
      
      The root cause of the issue stems from the function skip_rear_comments,
      which was a work around to remove "extra" "*/" characters from the query
      text, when parsing a query and reusing the text fragments to represent a
      view, trigger, function or stored procedure.
      The reason for this work around is that "special comments",
      like /*!50002 XXX */, were not parsed properly, so that a query like:
        AAA /*!50002 BBB */ CCC
      would be seen by the parser as "AAA BBB */ CCC" when the current version
      is greater or equal to 5.0.2
      
      The root cause of this stems from how special comments are parsed.
      Special comments are really out-of-bound text that appear inside a query,
      that affects how the parser behave.
      In nature, /*!50002 XXX */ in MySQL is similar to the C concept
      of preprocessing :
        #if VERSION >= 50002
        XXX
        #endif
      
      Depending on the current VERSION of the server, either the special comment
      should be expanded or it should be ignored, but in all cases the "text" of
      the query should be re-written to strip the "/*!50002" and "*/" markers,
      which does not belong to the SQL language itself.
      
      Prior to this fix, these markers would leak into :
      - the storage format for VIEW,
      - the storage format for FUNCTION,
      - the storage format for FUNCTION parameters, in mysql.proc (param_list),
      - the storage format for PROCEDURE,
      - the storage format for PROCEDURE parameters, in mysql.proc (param_list),
      - the storage format for TRIGGER,
      - the binary log used for replication.
      
      In all cases, not only this cause format corruption, but also provide a vector
      for dormant security issues, by allowing to tunnel code that will be activated
      after an upgrade.
      
      The proper solution is to deal with special comments strictly during parsing,
      when accepting a query from the outside world.
      Once a query is parsed and an object is created with a persistant
      representation, this object should not arbitrarily mutate after an upgrade.
      In short, special comments are a useful but limited feature for MYSQLdump,
      when used at an *interface* level to facilitate import/export,
      but bloating the server *internal* storage format is *not* the proper way
      to deal with configuration management of the user logic.
      
      With this fix:
      - the Lex_input_stream class now acts as a comment pre-processor,
      and either expands or ignore special comments on the fly.
      - MYSQLlex and sql_yacc.yy have been cleaned up to strictly use the
      public interface of Lex_input_stream. In particular, how the input stream
      accepts or rejects a character is private to Lex_input_stream, and the
      internal buffer pointers of that class are strictly private, and should not
      be tempered with during parsing.
      
      This caused many changes mostly in sql_lex.cc.
      
      During the code cleanup in case MY_LEX_NUMBER_IDENT,
      Bug 28127 (Some valid identifiers names are not parsed correctly)
      was found and fixed.
      
      By parsing special comments properly, and removing the function
      'skip_rear_comments' [sic],
      Bug 26302 (MySQL server cuts off trailing "*/" from comments in SP/func)
      has been fixed as well.
      a508260b
  36. 10 Jun, 2007 1 commit
    • kostja@bodhi.(none)'s avatar
      Follow up after work on Bug 4968 · 6c352d16
      kostja@bodhi.(none) authored
      Coding style: classes start with a capital letter.
      Rename some classes related to parsing:
      create_field -> Create_field
      foreign_key -> Foreign_key
      key_part_spec -> Key_part_spec
      6c352d16
  37. 04 Jun, 2007 1 commit