Skip to content

M
MariaDB
Switch branch/tag
  1. 06 Sep, 2006 5 commits
    • unknown's avatar
      Fix build problem for when not compiled with debugging. · daa1d028
      unknown authored 
      
dbug/dbug.c:
  Don't try to force DBUG on.
  
  Conditionally compile this file, as the headers we load may change the 
  value of DBUG_OFF /after/ we set it.
      daa1d028
    • unknown's avatar
      Fix merge problems; work around disparate "ls" behaviors. · 5e9324a8
      unknown authored 
      
mysql-test/r/ctype_recoding.result:
  Case change in 5.1.
mysql-test/t/heap_btree.test:
  Fixes bad merge.
mysql-test/t/partition.test:
  Split terrible "ls" test into two parts so that the different sorting orders
  of sundry OSes don't affect the output.
      5e9324a8
    • unknown's avatar
      mi_test_all.sh needs "./" before the executable names otherwise they · ff825de6
      unknown authored 
      are not found


storage/myisam/mi_test_all.sh:
  need "./" before the executable names otherwise they are not found
      ff825de6
    • unknown's avatar
      Merge gbichot@bk-internal.mysql.com:/home/bk/mysql-5.1-maint · 325c699e
      unknown authored 
      into  gbichot3.local:/home/mysql_src/mysql-5.1-2
      325c699e
    • unknown's avatar
      New way to fix BUG#19243 "wrong LAST_INSERT_ID() after ON DUPLICATE KEY UPDATE". · c3cef377
      unknown authored 
      This bug report was two problems:
1) LAST_INSERT_ID() returns a value which does not exist in the table
2) the reporter would want it to return the autoinc id of the updated
row.
1) is a real bug, 2) is a feature request.
In July I implemented 2) in 5.1 (which automatically fixes 1).
This has not yet been documented or released, so is changeable.
Precisely, recently Paul and a user found an easy workaround to give
2), which works in 4.1-5.0-5.1. So I can revert my code for 2),
because it's not needed, that's what I do here;
we forget about 2) (we will document the workaround).
But when I revert my code for 2), 1) comes back. We solve 1) by saying
that if INSERT ON DUPLICATE KEY UPDATE updates a row, it's like a
regular UPDATE: LAST_INSERT_ID() should not be affected (instead of
returning a non-existent value).
So note: no behaviour change compared to the last released 5.1; just
a bugfix for 1).


mysql-test/r/innodb_mysql.result:
  result update
mysql-test/t/innodb_mysql.test:
      test for the new way to fix BUG#19243: that if INSERT ON DUPLICATE
      KEY UPDATE updates a row, SELECT LAST_INSERT_ID() is not affected.
      Test of the workaround for people who want SELECT LAST_INSERT_ID()
      to return the autoinc id of the updated row.
sql/sql_insert.cc:
  No need to change LAST_INSERT_ID() if INSERT ON DUPLICATE KEY UPDATE
  updates a row, there is a workaround to achieve this without changing
  code: just add "autoinc_col=LAST_INSERT_ID(autoinc_col)" to your
  ON DUPLICATE KEY UPDATE clause.
  Prevent LAST_INSERT_ID() to contain an inexistent value in this case:
  if the row is updated it should be like a regular UPDATE: don't
  affect LAST_INSERT_ID() (achieved by marking that we didn't generate
  an id for this row: insert_id_for_cur_row=0).
      c3cef377
  3. 05 Sep, 2006 35 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7