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
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... |