Warning message during update of geshinode module to 6.x-1.3 on PostgreSQL

I don't have access to a setup with PostgreSQL, so it's a bit hard to dive into this.

The message you cited mentions both "warning" and "error". I wonder if it the update really failed (meaning that it stopped updating after the error) or just raised a warning and continued the rest of the update.

This is the update function that is responsible for the database update we are talking about:

/**
 * Implementation of hook_update_N().
 *
 * Fix the primary key and indices on the geshinode table.
 * See http://drupal.org/node/363770 .
 */
function geshinode_update_6001() {
  $ret = array();
  // Drop unique key on 'vid'.
  db_drop_unique_key($ret, 'geshinode', 'vid');
  // Change the 'nid' field to 'int' (from 'serial').
  db_change_field($ret, 'geshinode', 'nid', 'nid',
    array(
      'description' => t('The primary identifier for a node.'),
      'type' => 'int',
      'unsigned' => TRUE,
      'not null' => TRUE,
    )
  );
  // Drop primary key ('nid').
  db_drop_primary_key($ret, 'geshinode');
  // Add primary key on 'vid'.
  db_add_primary_key($ret, 'geshinode', array('vid'));
  // Add an index on 'nid'.
  db_add_index($ret, 'geshinode', 'nid', array('nid'));
  return $ret;
}

The error/warning is from the following line I guess:

 db_drop_primary_key($ret, 'geshinode');

Can you check if the following database updates were executed:

// Add primary key on 'vid'.
  db_add_primary_key($ret, 'geshinode', array('vid'));
  // Add an index on 'nid'.
  db_add_index($ret, 'geshinode', 'nid', array('nid'));

E.g.: is there a primary key on 'vid' in the 'geshinode' table and is there an index on 'nid'?

Sorry for the delay, but I didn't had the time to look into this in more depth.

it might be easily fixed by exchanging the order of those two function calls.

Changing the update to

  // Drop primary key ('nid').
  db_drop_primary_key($ret, 'geshinode');
  // Change the 'nid' field to 'int' (from 'serial').
  db_change_field($ret, 'geshinode', 'nid', 'nid', array('description' => t('The primary identifier for a node.'), 'type' => 'int', 'unsigned' => TRUE, 'not null' => TRUE));

does not work on MySQL.
The drop of primary key on "geshinode.nid" fails with message:

Incorrect table definition; there can be only one auto column and it must be defined as a key.
Query: ALTER TABLE geshinode DROP PRIMARY KEY in /var/www/test1/includes/database.mysql-common.inc on line 386.

Explanation: before the update, geshinode.nid was of type "serial" (aka autoinrement) instead of "int" and had a primary index on it. Apparently in MySQL, if you have an autoincrement column, it has too be primary key too. So you can't drop the index before changing it from serial to int (maybe this is the case in PostgreSQL too?). That's why db_change_field() has to come before db_drop_primary_key().

Also note that because the dropping of the primary key on "geshinode.nid" failed, the adding of (a second) primary key on vid also fails:

 // Add primary key on 'vid'.
  db_add_primary_key($ret, 'geshinode', array('vid'));

with

Multiple primary key defined.
Query: ALTER TABLE geshinode ADD PRIMARY KEY (vid) in /var/www/test1/includes/database.mysql-common.inc on line 374.

One option is to put a database specific test around the db_drop_primary_key():

// Drop primary key on 'nid'. We don't have to do this for PostgreSQL, 
// because the db_change_field() call above already took care of this.
global $db_type;
if ($db_type != 'pgsql') {
  db_drop_primary_key($ret, 'geshinode');
}

However I don't like database specific code (makes it harder to test things, and it assumes a behavior of postgreSQL that could change in the future). So the other option, which I am more inclined to is flagging this issue as "wont't fix".
The current update function works on both MySQL and PostgreSQL. With PostgreSQL, you get a warning/error message, but as you reported, it is safe to ignore this.

For now, I'd set this (rather minor) issue to "won't fix". If you disagree, I'm open to discuss this further.