Paul Edwards <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
