4.7 CVS updates.inc inconsistent

Hi,

I've been checking on an issue (see screenshot) with the Drupal update script. I believe the following discrepancy is what is causing the issue:

4.6.2/4.6.3 updates.inc: v 1.100.2.5 2005/05/07 08:36:24: Lines 107-111

  "2005-03-21" => "update_128",
  "2005-04-14" => "update_129",
  "2005-05-06" => "update_130",
  "2005-05-07" => "update_131"
);

4.7 CVS: updates.inc: v 1.148 2005/11/18 14:05:38: Lines 81 - 103

  "2005-03-21" => "update_128",
  "2005-04-08: first update since Drupal 4.6.0 release" => "update_129",
  "2005-04-10" => "update_130",
  "2005-04-11" => "update_131",
  "2005-04-14" => "update_132",
  "2005-04-24" => "update_133",
  "2005-04-30" => "update_134",
  "2005-05-06" => "update_135",
  "2005-05-08" => "update_136",
  "2005-05-09" => "update_137",
  "2005-05-10" => "update_138",
  "2005-05-11" => "update_139",
  "2005-05-12" => "update_140",
  "2005-05-22" => "update_141",
  "2005-07-29" => "update_142",
  "2005-07-30" => "update_143",
  "2005-08-08" => "update_144",
  "2005-08-15" => "update_145",
  "2005-08-25" => "update_146",
  "2005-09-07" => "update_147",
  "2005-09-18" => "update_148",
  "2005-09-27" => "update_149",
  "2005-10-15" => "update_150",
  "2005-10-23" => "update_151",
  "2005-10-28" => "update_152",
  "2005-11-03" => "update_153",
  "2005-11-14" => "update_154"
);

So, for users who have upgraded to 4.6.3, their update_start is set to 2005-05-07. When they use the current (CVS) update.php file, the script finds no update for 2005-05-07 and resets to the beginning. However, everything appears to work fine if update_129 is chosen, but the user obviously doesn't know this.

Inconsistencies between MySQL and pgSQL update queries in updates.inc should also probably be kept in mind..

Also, as in the attached screenshots, the updated code causes something of a catch-22 with the watchdog INSERT statement.. The user can safely ignore it, but nevertheless if the logging can be turned off, or if all logging can be restricted only to the screen and not to the DB, this might not occur.

Thanks.