PDOException: SQLSTATE[42601]: Syntax error: 7 ERROR: syntax error at or near "(" LINE 1: ...field_geofield ALTER "field_geofield_lat" TYPE int(18, 12) U... ^: ALTER TABLE {field_data_field_geofield} ALTER "field_geofield_lat" TYPE int(18, 12) USING "field_geofield_lat"::int(18, 12); Array ( ) in db_change_field() (line 2985 of /Users/satchwinston/Sites/drupal7/includes/database/database.inc).

Got this updating to the latest version of Geofield. I hate it when stuff like this happens. (I'm using postgres if that matters)

Comments

teezee’s picture

Didn't test on postgres, but how come the field becomes int(18, 12) when the Drupal type is set to numeric?

Documentation at http://drupal.org/node/159605 states:

type      size       mysql type             postgres type               sqlite type
numeric   normal     numeric, 65 digits     numeric, 1000 digits        numeric

And postgres doc states that 'numeric' allows for user specified precision and scale (http://www.postgresql.org/docs/8.2/static/datatype-numeric.html). And the field type mapping in Drupal states that 'numeric' is mapped to 'numeric' (http://api.drupal.org/api/drupal/includes%21database%21pgsql%21schema.in...) so I dont get why your error message states 'int' types? Is Field API changing something perhaps?

Should it instead be more a 'big' float to work well for PG? Or should 'pgsql_type' be used in the schema to ensure PG uses 'numeric' instead of 'int'?

teezee’s picture

Title: Update Error » Field type update fails in PostgreSQL

Ah! Found that the changeField() method messes up the type casting, to avoid data loss or something:
http://api.drupal.org/api/drupal/includes%21database%21pgsql%21schema.in...

So Drupal's PostgreSQL code changes the field type to 'int' in field type updates when the pgsql type is in array('serial', 'bigserial', 'numeric').

Damn... no idea how to work around that yet... Will have to look into that.

phayes’s picture

This sounds like a bug in core and we should open a ticket

Brandonian’s picture

Yeesh, yeah, that's a problem. Can we workaround by adding a new field, copying data, then dropping the old field? Or, practically, adding a temp db field, copying data, dropping old field, create new field, then copy data back over?

phayes’s picture

I'd prefer to get this fixed in core *first*, then work on our own work-around. Maybe it's possible to detect postgres and do an SQL directly.

phayes’s picture

phayes’s picture

Issue summary: View changes

forgot a word