Re: About PostgreSQL's limit on arithmetic operations

Поиск
Список
Период
Сортировка
Искать
От
Guy Fraser
Тема
Re: About PostgreSQL's limit on arithmetic operations
Дата
Msg-id
4166CC70.3060200@incentre.net
Ответ на
Список
Дерево обсуждения
About PostgreSQL's limit on arithmetic operations Devrim GUNDUZ <devrim@gunduz.org>
Re: About PostgreSQL's limit on arithmetic operations Stephan Szabo <sszabo@megazone.bigpanda.com>
Re: About PostgreSQL's limit on arithmetic operations Shridhar Daithankar <shridhar@frodo.hserus.net>
Re: About PostgreSQL's limit on arithmetic operations Devrim GUNDUZ <devrim@gunduz.org>
Re: About PostgreSQL's limit on arithmetic operations Shridhar Daithankar <shridhar@frodo.hserus.net>
Re: About PostgreSQL's limit on arithmetic operations Martijn van Oosterhout <kleptog@svana.org>
Re: About PostgreSQL's limit on arithmetic operations Guy Fraser <guy@incentre.net>
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 method is used because it makes 
addition and
subtraction simpler for computers to perform on integers.

I am not sure how to declare an unsigned bigint, but if you can it would 
produce
the expected result.

Only Oracle developers could tell you why they would generate an invalid 
result when
doing math using 64 bit signed integers {9223372036854775808 is not a 
valid value
for a 64bit signed integer.} Just because Oracle gives you the number 
you want it
in no way makes the result correct. Since the result is outside the 
scope of a 64 bit
signed integer an overflow error could be a valid result, or the value 
postgresql
returns could also be a valid result. If you are multiplying by 512 in 
order to perform
a binary right shift of 9 bits on the integer you don't want scope 
validation, because if
were enforced a right shift would not work, and the result would produce 
an error.
Please read the documentation on data types, it details the scope 
{range} for all data
types. If you use the proper data type for your data set you can reduce 
the amount of
storage required for small numbers and be fairly certain that the math 
will work as
expected using large numbers.



Shridhar Daithankar wrote:

>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 results from other databases shows that they can perform
>>it without casting...
>>    
>>
>
>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 negative 
>sign..
>
>For arbitrary precision integer, you have to use numeric. It is not same as 
>oracle. 
>
>Furthermore if your number fit in range, then numbers like precision(4,0) in 
>oracle to smallint in postgresql would buy you huge speed 
>improvement(compared to postgresql numeric I mean)
>
>Please correct me if I am wrong..
> 
> Shridhar
>  
>

-- 
Guy Fraser
Network Administrator
The Internet Centre
780-450-6787 , 1-888-450-6787

There is a fine line between genius and lunacy, fear not, walk the
line with pride. Not all things will end up as you wanted, but you
will certainly discover things the meek and timid will miss out on.



В списке pgsql-general по дате отправления
От: Samik Raychaudhuri
Дата:
От: Patrick Hatcher
Дата:
Сообщение: Explain output question
FAQ