Re: Integer parsing bug? - Mailing list pgsql-bugs

From Steve Atkins
Subject Re: Integer parsing bug?
Date
Msg-id 20040303233446.GC25314@gp.word-to-the-wise.com
Whole thread Raw
In response to Re: Integer parsing bug?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Wed, Mar 03, 2004 at 06:27:07PM -0500, Tom Lane wrote:
> Steve Atkins <steve@blighty.com> writes:
> >> test=> select -2147483648::int;
> >> ERROR:  integer out of range
>
> There is no bug here.  You are mistakenly assuming that the above
> represents
>     select (-2147483648)::int;
> But actually the :: operator binds more tightly than unary minus,
> so Postgres reads it as
>     select -(2147483648::int);
> and quite rightly fails to convert the int8 literal to int.
>
> If you write it with the correct parenthesization it works:
>
> regression=# select -2147483648::int;
> ERROR:  integer out of range
> regression=# select (-2147483648)::int;

OK... That makes sense if the parser has no support for negative
constants, but it doesn't seem like intuitive behaviour.


BTW, the original issue that led to this was:

db=>CREATE function t(integer) RETURNS integer AS '
BEGIN
  return 0;
END;
' LANGUAGE 'plpgsql';

db=> select t(-2147483648);
ERROR:  function t(bigint) does not exist

Which again makes sense considering the way the parser works, but
still seems to violate the principle of least surprise.

Cheers,
  Steve

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Integer parsing bug?
Next
From: "PostgreSQL Bugs List"
Date:
Subject: BUG #1091: Localization in EUC_TW Can't decode Big5 0xFA40--0xFEF0.