Henson Choi <[email protected]> writes:
> pg_get_viewdef(..., true) and the other pretty-printing paths drop the
> parentheses around the test expression of a sublink, the left operand
> of IN, of op ANY/ALL or of a single-column row comparison, even where
> they are needed.  The text then reads back as another expression, or
> is rejected.  The two attached patches add tests and fix it.

Good catch.  I do not like your proposed fix though: it adds yet more
complexity that has to be kept in sync with gram.y and yet doesn't
line up nicely with the grammar's rules.  I think what we ought to
do for now is your "simple fix"

> 0002 prints the test expression with get_rule_expr_paren(),
> as for the operands of any other operator.  For a simple
> fix, that alone would do.

without the other stuff.  In the longer run, I'm interested in
investigating a more invasive improvement such as you mentioned:

> Longer term, it might be better to rework the parenthesization in
> ruleutils.c around one table of the gram.y precedence levels for all
> operators and expressions, instead of the special cases in
> isSimpleNode().

because otherwise we'll just keep having bugs of this sort.
(I'm already wondering whether we correctly deparse all the random
SQL/JSON syntax, for example.)  I wonder if there is any way to
get the necessary data built automatically from gram.y ...

                        regards, tom lane


Reply via email to