Re: BUG #1608: integer negative limit in plpgsql function arguments

I wrote:
> You're right, we do cheat a little on negative numeric constants --- I
> had forgotten about the doNegate() hack in gram.y. We could conceivably
> fix it to cheat some more. Specifically it looks like make_const() in
> parse_node.c could check for the possibility that a T_Float fits in INT4
> --- which would happen only for the case of -2147483648, since any
> smaller absolute value would have been T_Integer to start with.

I've applied the attached patch to CVS HEAD. I'm not going to risk
back-patching this, but feel free to use the patch locally if it's
important to you.

regards, tom lane

*** src/backend/parser/parse_node.c.orig Fri Dec 31 17:45:55 2004
--- src/backend/parser/parse_node.c Sat Apr 23 14:28:03 2005
***************
*** 304,314 ****
/* could be an oversize integer as well as a float ... */
if (scanint8(strVal(value), true, &val64))
{
! val = Int64GetDatum(val64);

! typeid = INT8OID;
! typelen = sizeof(int64);
! typebyval = false; /* XXX might change someday */
}
else
{
--- 304,331 ----
/* could be an oversize integer as well as a float ... */
if (scanint8(strVal(value), true, &val64))
{
! /*
! * It might actually fit in int32. Probably only INT_MIN can
! * occur, but we'll code the test generally just to be sure.
! */
! int32 val32 = (int32) val64;

! if (val64 == (int64) val32)
! {
! val = Int32GetDatum(val32);
!
! typeid = INT4OID;
! typelen = sizeof(int32);
! typebyval = true;
! }
! else
! {
! val = Int64GetDatum(val64);
!
! typeid = INT8OID;
! typelen = sizeof(int64);
! typebyval = false; /* XXX might change someday */
! }
}
else
{