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:
Tom Lane 2008-06-06 18:00:00 +00:00
parent 5272652720
commit 0bb7588aee

View File

@ -3,7 +3,7 @@
* back to source text
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/utils/adt/ruleutils.c,v 1.188.4.7 2008/01/06 01:03:37 tgl Exp $
* $PostgreSQL: pgsql/src/backend/utils/adt/ruleutils.c,v 1.188.4.8 2008/06/06 18:00:00 tgl Exp $
*
* This software is copyrighted by Jan Wieck - Hamburg.
*
@ -3774,10 +3774,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 */
}