Skip site navigation (1) Skip section navigation (2)

Re: int4, int8, real ....division...

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: gyenese(at)mediagnost(dot)hu, pgsql-bugs(at)postgresql(dot)org
Subject: Re: int4, int8, real ....division...
Date: 2004-05-21 10:42:13
Message-ID: 40ADDD05.4090104@samurai.com (view raw or flat)
Thread:
Lists: pgsql-bugs
Tom Lane wrote:
> This isn't a division problem --- the difficulty is there's no check for
> overflow in int4 multiplication.  (Nor in any of the other integer
> arithmetic operations, for that matter.)

It seems to me that SQL2003, Section 6.26 (<numeric value expression>, 
"General Rules", item 5) requires that we check for overflow after 
arithmetic operations on exact numeric types:

%%%%
5) If the most specific type of the result of an arithmetic operation is
exact numeric, then

Case:

a) If the operator is not division and the mathematical result of the
operation is not exactly representable with the precision and scale of
the result data type, then an exception condition is raised: data
exception — numeric value out of range.

b) If the operator is division and the approximate mathematical result
of the operation represented with the precision and scale of the result
data type loses one or more leading significant digits after rounding or
truncating if necessary, then an exception condition is raised: data
exception — numeric value out of range. The choice of whether to round
or truncate is implementation-defined.
%%%%

Or am I misreading the spec?

-Neil


In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2004-05-21 14:15:48
Subject: Re: int4, int8, real ....division...
Previous:From: Tom LaneDate: 2004-05-21 06:34:21
Subject: Re: LATIN2 'bssz' and 'bszsz' fails on unique index

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group