Remove empty update functions

Maybe I am giving the wrong interpretation to something I read, but update function should never renamed; I take it that an update function cannot be deleted.

Are you able to provide an example of Drupal core module that removed an update function from the installation file?

The point is that creating empty update functions is pointless and a waste of time. It makes more function calls in the update progress. Anyone who is updating from 5.x-2.x, when the run update.php, all these update update functions will run. What is the point?

What you should do is remove any empty update functions except for the last one, if it's the last update function in the module. It's bad practice to have empty update functions. Drupal core tries to avoid them at all costs.

I didn't create empty update functions, but they became empty because the code has been moved to a different update function. This is partially caused from my misunderstanding of how the update functions are called.
I thought Drupal would call only the latest update function (I know it's a silly idea, and I don't know from what I took that idea), so I keep to move the code from a function to another because update functions cannot be renamed.

If there aren't any problems in removing such functions, I will do it.

I have changed the code, and committed the changes in CVS.

I think that the documentation, which says (or said) to not rename an update function should be clearer on that. An update function should not be renamed to make its update number lower.

Anyway, this is not a bug report, but a task.

As long as I can see, the patch is renaming the update functions, which is not allowed.

The answer to the question why are we deleting all the rows of the table is that the content of the table is being deleted because the primary key is being changed with an auto-incremental field; being this the case, the only way to give to the primary key the correct value is to re-populate the table.

The part of the patch that is wrong is the following:

-/**
- * Implementation of hook_update_N().
  *
+ * @TODO: Why is this calling a previous update?
  */
-function xmlsitemap_taxonomy_update_6112() {
-  return array();
+function xmlsitemap_taxonomy_update_6107() {
+  return xmlsitemap_taxonomy_update_6000();
 }

The update #6112 is renamed 6107; this means that who already had installed a beta version, would not see any new update until you don't use an update number greater than 6112 again. As I am talking of a beta version, the case doesn't fall into the inter-dev update (and the consequent silliness).

Talking of inter-dev update, a question comes in: if the inter-dev updates are not supported (which is not the case of other modules), why would a developer increase the update number of the functions? It would be enough to create a unique update function that would do all the update tasks necessary. The inter-dev updates are not supported; therefore, using a different update function each times would not make sense, as who install the latest development version is forced to uninstall the older one, without to even make an update.

Just dropping the key, adding the serial column and declaring it the primary key is enough.

It's not what happened to me when I tested the update function; the SQL query that adds the new primary key doesn't update the existing rows.
It's enough to see the code for the following Drupal core function:

function db_add_primary_key(&$ret, $table, $fields) {
  $ret[] = update_sql('ALTER TABLE {'. $table .'} ADD PRIMARY KEY ('.
    implode(',', $fields) .')');
}