Re: BUG #1608: integer negative limit in plpgsql function arguments
От | Tom Lane |
---|---|
Тема | Re: BUG #1608: integer negative limit in plpgsql function arguments |
Дата | |
Msg-id | 13095.1114281440@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #1608: integer negative limit in plpgsql function arguments (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
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 {
В списке pgsql-bugs по дате отправления: