The problem is occurring with a database that was restored with psql
from a pg_dump (6.5.2).
If I dump the problem table, then drop/recreate it with my original
table creation commands, and then reload with only the insert commands
from the pg_dump'ed file, it reloads and allows updating of the float
field without a problem. Testing my entire DB to find other problem
float fields is painful; doing this drop/recreate process would be
even more so.
As you can see below, this makes no sense given '\d' shows the field
is a float4 yet the code is trying to call pg_atoi on the new value...
I'm still looking into this more to understand what hoops I may have
to jump through to salvage/reuse pg_dump output...any tips would be
appreciated.
Ed Loehr wrote:
>
> Can someone enlighten me why this error is occurring in which a float
> value is apparently being interpreted as an integer? Known
> workarounds??
>
> emsdb=> UPDATE contract_activity_type SET duration = 3.5, updater_id
> = 1, last_update = now() WHERE id = 72;
> ERROR: pg_atoi: error in "3.5": can't parse ".5"
> emsdb=> \d contract_activity_type
> Table = contract_activity_type
> +----------------------------------+----------------------------------+-------+
> | Field | Type
> | Length|
> +----------------------------------+----------------------------------+-------+
> | id | int4 not null default nextval (
> | 4 |
> | contract_id | int4 not null
> | 4 |
> | activity_type_id | int4 not null
> | 4 |
> | travel_required | int4 not null
> | 4 |
> | billable | int4 not null
> | 4 |
> | duration | float4 not null
> | 4 |
> ...
>
> Thanks in advance.
>
> Cheers,
> Ed Loehr