Re: [HACKERS] float4 confused as int??

From: Ed Loehr <eloehr(at)austin(dot)rr(dot)com>
To: pghackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] float4 confused as int??
Date: 2000-01-31 20:05:36
Message-ID: 3895EB10.CC9EC4A9@austin.rr.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Peter Landis 2000-01-31 20:35:43 SQL Book
Previous Message Marc Tardif 2000-01-31 18:43:17 automatic timestamp

Browse pgsql-hackers by date

  From Date Subject
Next Message The Hermit Hacker 2000-01-31 21:34:42 PClabs Survey, Part I: Administration
Previous Message Patrick Welche 2000-01-31 19:13:56 Re: [HACKERS] Another nasty cache problem