1. 19 Jun, 2007 1 commit
  2. 18 Jun, 2007 1 commit
  3. 15 Jun, 2007 3 commits
  4. 14 Jun, 2007 23 commits
  5. 13 Jun, 2007 3 commits
  6. 12 Jun, 2007 9 commits
    • 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
    • gkodinov/kgeorge@magare.gmz's avatar
      Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.1-opt · 72f395a5
      gkodinov/kgeorge@magare.gmz authored
      into  magare.gmz:/home/kgeorge/mysql/autopush/B27816-5.1-opt
      72f395a5
    • gkodinov/kgeorge@magare.gmz's avatar
      Merge bk-internal:/home/bk/mysql-5.1-opt · 0d6bae22
      gkodinov/kgeorge@magare.gmz authored
      into  magare.gmz:/home/kgeorge/mysql/work/merge-5.1-opt
      0d6bae22
    • gkodinov/kgeorge@magare.gmz's avatar
      5.0-opt -> 5.1-opt merge · eb1fb609
      gkodinov/kgeorge@magare.gmz authored
      eb1fb609
    • gkodinov/kgeorge@magare.gmz's avatar
      Merge bk-internal:/home/bk/mysql-5.0-opt · fbefe9d5
      gkodinov/kgeorge@magare.gmz authored
      into  magare.gmz:/home/kgeorge/mysql/work/merge-5.1-opt
      fbefe9d5
    • holyfoot/hf@hfmain.(none)'s avatar
      Merge bk@192.168.21.1:mysql-5.1-opt · 79f0900f
      holyfoot/hf@hfmain.(none) authored
      into  mysql.com:/home/hf/work/28757/my51-28757
      79f0900f
    • holyfoot/hf@mysql.com/hfmain.(none)'s avatar
      Bug #28757 Test program / embedded server crash in test "unsafe_binlog_innodb" · 70933107
      holyfoot/hf@mysql.com/hfmain.(none) authored
      the reported test failure is fixed by the patch to 28333,
      but there's a bit more to fix in the test itself - to
      drop tables created in this test at the test's beginning.
      70933107
    • mhansson/martin@linux-st28.site's avatar
      Bug#27634: group_by test fails · 660d6475
      mhansson/martin@linux-st28.site authored
      On many architectures, e.g. 68000, x86, the double registers have higher precision 
      than the IEEE standard prescribes. When compiled with flags -O and higher, some double's 
      go into registers and therefore have higher precision. In one test case the cost 
      information of the best and second-best key were close enough to be influenced by this 
      effect, causing a failed test in distribution builds.
      
      Fixed by removing some rows from the table in question so that cost information is not
      influenced by decimals beyond standard definition of double.
      660d6475
    • gkodinov/kgeorge@magare.gmz's avatar
      removed compilation warning · 2a6ac40e
      gkodinov/kgeorge@magare.gmz authored
      2a6ac40e