Thread: BUG #15458: pg_typeof inconsistency on negative integer constantlimits

The following bug has been logged on the website:

Bug reference:      15458
Logged by:          Elvis Pranskevichus
Email address:      elprans@gmail.com
PostgreSQL version: 11.0
Operating system:   x86_64-pc-linux-gnu
Description:

There seems to be an inconsistency in how the parser and the integer input
functions interpret the integers at the negative limit (-2 ^ 31 and -2 ^
63):


SELECT pg_typeof(-2147483648);

 pg_typeof
-----------
 integer
(1 row)

But:

SELECT -2147483648::integer;
ERROR:  integer out of range


The same issue applies to int8 as well.

PG_INT32_MIN is explicitly defined as -(2 ^ 31 - 1), and it seems 
inconsistent that the parser does not respect that when determining the 
type of numeric constants.

Hi,

On 2018-10-24 20:47:21 +0000, PG Bug reporting form wrote:
> The following bug has been logged on the website:
> 
> Bug reference:      15458
> Logged by:          Elvis Pranskevichus
> Email address:      elprans@gmail.com
> PostgreSQL version: 11.0
> Operating system:   x86_64-pc-linux-gnu
> Description:        
> 
> There seems to be an inconsistency in how the parser and the integer input
> functions interpret the integers at the negative limit (-2 ^ 31 and -2 ^
> 63):
> 
> 
> SELECT pg_typeof(-2147483648);
> 
>  pg_typeof
> -----------
>  integer
> (1 row)
> 
> But:
> 
> SELECT -2147483648::integer;
> ERROR:  integer out of range

> 
> The same issue applies to int8 as well.
> 
> PG_INT32_MIN is explicitly defined as -(2 ^ 31 - 1), and it seems 
> inconsistent that the parser does not respect that when determining the 
> type of numeric constants.

It's just a precedence issue. :: binds with higher precedence, so the
above is actually -(2147483648::integer), rather than
(-2147483648)::integer. Therefore you get an overflow.

Greetings,

Andres Freund

On Wednesday, October 24, 2018 4:54:32 PM EDT Andres Freund wrote:
> Hi,
> 
> On 2018-10-24 20:47:21 +0000, PG Bug reporting form wrote:
> > The following bug has been logged on the website:
> > 
> > Bug reference:      15458
> > Logged by:          Elvis Pranskevichus
> > Email address:      elprans@gmail.com
> > PostgreSQL version: 11.0
> > Operating system:   x86_64-pc-linux-gnu
> > Description:
> > 
> > There seems to be an inconsistency in how the parser and the integer
> > input functions interpret the integers at the negative limit (-2 ^
> > 31 and -2 ^ 63):
> > 
> > 
> > SELECT pg_typeof(-2147483648);
> > 
> >  pg_typeof
> > 
> > -----------
> > 
> >  integer
> > 
> > (1 row)
> > 
> > But:
> > 
> > SELECT -2147483648::integer;
> > ERROR:  integer out of range
> > 
> > 
> > The same issue applies to int8 as well.
> > 
> > PG_INT32_MIN is explicitly defined as -(2 ^ 31 - 1), and it seems
> > inconsistent that the parser does not respect that when determining
> > the type of numeric constants.
> 
> It's just a precedence issue. :: binds with higher precedence, so the
> above is actually -(2147483648::integer), rather than
> (-2147483648)::integer. Therefore you get an overflow.

Ah, you're right.  Sorry for the noise.


                              Elvis

>> SELECT -2147483648::integer;
>> ERROR:  integer out of range
>
> It's just a precedence issue. :: binds with higher precedence, so the
> above is actually -(2147483648::integer), rather than
> (-2147483648)::integer. Therefore you get an overflow.

The error message may be nicer by expliciting the offending string, and/or 
locating it precisely within the query?

-- 
Fabien.

Hi,

On 2018-10-26 08:02:59 +0200, Fabien COELHO wrote:
> 
> > > SELECT -2147483648::integer;
> > > ERROR:  integer out of range
> > 
> > It's just a precedence issue. :: binds with higher precedence, so the
> > above is actually -(2147483648::integer), rather than
> > (-2147483648)::integer. Therefore you get an overflow.
> 
> The error message may be nicer by expliciting the offending string, and/or
> locating it precisely within the query?

Including the string would make the function not leak proof though, so
that seems like a no-go.  Location would be possible, but there's some
architectural issues around doing so at execution time - we only really
have the setup to do so at parse time currently.  Tom was looking to
change that at some point however, iirc.

Greetings,

Andres Freund

Andres Freund <andres@anarazel.de> writes:
> On 2018-10-26 08:02:59 +0200, Fabien COELHO wrote:
>> The error message may be nicer by expliciting the offending string, and/or
>> locating it precisely within the query?

> Including the string would make the function not leak proof though, so
> that seems like a no-go.  Location would be possible, but there's some
> architectural issues around doing so at execution time - we only really
> have the setup to do so at parse time currently.  Tom was looking to
> change that at some point however, iirc.

Yeah.  That project was on hold till you got done whacking expression
execution around; but if that's about finished, I might take another look.

            regards, tom lane