Re: [HACKERS] Bug?

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: Michael Meskes <meskes(at)topsystem(dot)de>
Cc: PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Bug?
Date: 1998-02-05 15:39:54
Message-ID: 34D9DD4A.6A5F8EE0@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> I'm currently back to work with version 6.2.1 since I cannot connect with
> 6.3 via ODBC.
>
> Anyway, I got my application running after finding a problem (inside the
> app) with data conversion (it read double from a long data field). But it
> seems I also encountered what I believe to be a bug. Since I'm nor sure
> whether it's known I bring it up here. If I try to insert 199802051215 to a
> float8 field it doesn't work because the parser believes this is a long and
> truncates it to 2147...... Using 199802051215.0 to make sure it's a float
> works fine. Shouldn't the parser be able to handle this?

The current v6.3beta behavior is this:

postgres=> select 199802051215;
ERROR: Bad integer input '199802051215'

We had a bit of a discussion about the best way to handle this, and decided to
try Bruce's solution to reject the input as a first step. I have patches to do
the automatic conversion to a float, but have not applied them.

The other approach would lead to an error looking like:

postgres=> insert into t values (199802051215.0);
ERROR: pg_atoi: error reading "199802051215.000000": Math result not
representable

I can see arguments for both approaches; do you have a strong opinion either
way?

- Tom

In response to

  • Bug? at 1998-02-05 11:12:31 from Michael Meskes

Browse pgsql-hackers by date

  From Date Subject
Next Message Meskes, Michael 1998-02-05 15:43:18 RE: [HACKERS] Preprocessor
Previous Message Thomas G. Lockhart 1998-02-05 15:22:46 Re: [HACKERS] Linux: linux.s / tas.s not found...