BUG #15458: pg_typeof inconsistency on negative integer constant limits

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