1. 19 Feb, 2007 2 commits
    • gkodinov/kgeorge@rakia.gmz's avatar
      Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · 8f52c5b2
      gkodinov/kgeorge@rakia.gmz authored
      into  rakia.gmz:/home/kgeorge/mysql/autopush/B25831-5.0-opt
      8f52c5b2
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #25831: Deficiencies in INSERT ... SELECT ... field name resolving. · d17ad7b3
      gkodinov/kgeorge@macbook.gmz authored
       Several problems fixed: 
        1. There was a "catch-all" context initialization in setup_tables()
          that was causing the table that we insert into to be visible in the 
          SELECT part of an INSERT .. SELECT .. statement with no tables in
          its FROM clause. This was making sure all the under-initialized
          contexts in various parts of the code are not left uninitialized.
          Fixed by removing the "catch-all" statement and initializing the 
          context in the parser.
        2. Incomplete name resolution context when resolving the right-hand
          values in the ON DUPLICATE KEY UPDATE ... part of an INSERT ... SELECT ...
          caused columns from NATURAL JOIN/JOIN USING table references in the
          FROM clause of the select to be unavailable.
          Fixed by establishing a proper name resolution context.
        3. When setting up the special name resolution context for problem 2
          there was no check for cases where an aggregate function without a
          GROUP BY effectively takes the column from the SELECT part of an 
          INSERT ... SELECT unavailable for ON DUPLICATE KEY UPDATE.
          Fixed by checking for that condition when setting up the name 
          resolution context.
      d17ad7b3
  2. 16 Feb, 2007 5 commits
  3. 15 Feb, 2007 1 commit
  4. 13 Feb, 2007 5 commits
  5. 12 Feb, 2007 16 commits
  6. 11 Feb, 2007 3 commits
  7. 09 Feb, 2007 7 commits
  8. 08 Feb, 2007 1 commit