db_update_field()'s purpose is to synchronize a field definition with the current results of hook_schema(), including automatically recreating keys and indexes on pgsql if necessary. However, for the same reasons I wrote in http://drupal.org/node/150220, db_update_field() cannot be used safely in hook_update_n() functions. This means that system_update_6019(), which I wrote, is broken.

The solution is to use db_change_field() which takes an explicit field specification. On pgsql, db_change_field() does not automatically re-create any keys or indexes in which changed column is involved, so if the column is involved in a key or index it must be explicitly dropped and re-created (using db_{drop,add}_{primary_key,unique_key,index}()).

Note that db_change_field() is the functional equivalent of db_change_column() (which is pgsql-only) and db_change_column() is used all over system.install. So, using db_change_field() just preserves the status quo.

Making db_update_field() and a hypothetical db_update_table() or db_update_schema() function work would be great but is complicated and is the subject of another issue: http://drupal.org/node/149095.

Patch forthcoming.

Comments

bjaspan’s picture

Status: Active » Closed (duplicate)

This bug is subsumed into http://drupal.org/node/157682.