From: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
---|---|
To: | Devrim GUNDUZ <devrim(at)gunduz(dot)org> |
Cc: | PostgreSQL Mailing Lists-General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: About PostgreSQL's limit on arithmetic operations |
Date: | 2004-09-29 15:06:27 |
Message-ID: | 20040929080121.Q59588@megazone.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, 29 Sep 2004, Devrim GUNDUZ wrote:
> We were performing some tests on PostgreSQL and found that it fails on the
> following query:
>
> SELECT 512*18014398509481984 AS result;
>
> and the result is:
>
> result
> - ----------------------
> -9223372036854775808
This query should either return the "correct" answer or error. The
constants are probably getting typed as int4 and int8 but the result
overflows int8. If we say that the result of an int8 and int4 must be
within the int8 precision (which appears to be allowed by the spec,
although may not be what was inteneded) then it should error.
We don't currently check the overflow cases for int<n> to generate the
error, and we don't upgrade smaller integer types into numerics if it
would have overflowed. At some point we probably need to do one of those,
but AFAIK noone's been particularly motivated to do it.
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2004-09-29 15:09:32 | Re: Setting search paths inside a function (plpgsql) |
Previous Message | Graeme Hinchliffe | 2004-09-29 15:03:53 | string is sometimes null ? |