Signed integers use a number system known as "two's compliment" and in
order to
make room for negative numbers the most significant bit is used to
indicate a negative
value and the compliment of the rest of the bits minus 1 {there is no
such number as -0}
evaluate to the negative numbers. This m
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 e
On Wed, Sep 29, 2004 at 04:51:30PM +0530, Shridhar Daithankar wrote:
> Probably because the normal integer is 4 bytes long and bigint is 8 bytes
> long. The value above is exactly 2^63 at which a 8 bytes long signed bigint
> should flip sign/overflow. I am still puzzled with correct value and neg
On Wednesday 29 Sep 2004 2:25 pm, Devrim GUNDUZ wrote:
> > template1=# SELECT 512*18014398509481984::numeric(20) AS result;
> > result
> > -
> > 9223372036854775808
> > (1 row)
>
> Ok, I got the same result in 7.4.5... But... Why do we have to cast it
> into numeric? The r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On Wed, 29 Sep 2004, Shridhar Daithankar wrote:
SELECT 512*18014398509481984 AS result;
and the result is:
result
--
-9223372036854775808
It should be 9223372036854775808... This is PostgreSQL 7.4.5 on Fedora
Core 2.
On Wednesday 29 Sep 2004 1:11 pm, Devrim GUNDUZ wrote:
> Hi,
>
> 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
>
>
