Fix pg_get_ruledef() so that negative numeric constants are parenthesized.
This is needed because :: casting binds more tightly than minus, so for example -1::integer is not the same as (-1)::integer, and there are cases where the difference is important. In particular this caused a failure in SELECT DISTINCT ... ORDER BY ... where expressions that should have matched were seen as different by the parser; but I suspect that there could be other cases where failure to parenthesize leads to subtler semantic differences in reloaded rules. Per report from Alexandr Popov.
This commit is contained in:
parent
700af334cc
commit
c1943dbaef
@ -9,7 +9,7 @@
|
||||
*
|
||||
*
|
||||
* IDENTIFICATION
|
||||
* $PostgreSQL: pgsql/src/backend/utils/adt/ruleutils.c,v 1.274 2008/05/12 00:00:51 alvherre Exp $
|
||||
* $PostgreSQL: pgsql/src/backend/utils/adt/ruleutils.c,v 1.275 2008/06/06 17:59:29 tgl Exp $
|
||||
*
|
||||
*-------------------------------------------------------------------------
|
||||
*/
|
||||
@ -4479,10 +4479,19 @@ get_const_expr(Const *constval, deparse_context *context, int showtype)
|
||||
*
|
||||
* In reality we only need to defend against infinity and NaN,
|
||||
* so we need not get too crazy about pattern matching here.
|
||||
*
|
||||
* There is a special-case gotcha: if the constant is signed,
|
||||
* we need to parenthesize it, else the parser might see a
|
||||
* leading plus/minus as binding less tightly than adjacent
|
||||
* operators --- particularly, the cast that we might attach
|
||||
* below.
|
||||
*/
|
||||
if (strspn(extval, "0123456789+-eE.") == strlen(extval))
|
||||
{
|
||||
appendStringInfoString(buf, extval);
|
||||
if (extval[0] == '+' || extval[0] == '-')
|
||||
appendStringInfo(buf, "(%s)", extval);
|
||||
else
|
||||
appendStringInfoString(buf, extval);
|
||||
if (strcspn(extval, "eE.") != strlen(extval))
|
||||
isfloat = true; /* it looks like a float */
|
||||
}
|
||||
|
Loading…
x
Reference in New Issue
Block a user