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

Paul Edwards <paul(at)allinea(dot)com> writes:
> Also, just as an experiment I tried the minimum limit for bigint (see
> attached file). It seems that I do not need to cast for negative limit
> which is inconsistent since 9223372036854775808 is not a bigint (when
> -9223372036854775808 is). Therefore the type wasn't necessarily
> determined before the unary operator.

Really? [ tries it ... then reads some code ... ]

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.

This also brings up the thought that maybe the T_Integer case should
create an INT2 rather than INT4 Const if the value is small enough.
I'm fairly hesitant to do that though because it would be a significant
change in behavior, possibly breaking apps that don't have a problem
now. (IIRC we experimented with such a change some years back and saw
widespread failures in the regression tests, for example.)

However changing the behavior only for -2147483648 seems like a
relatively safe thing to do.

Thoughts, objections anyone?

regards, tom lane