Re: [DEPARSE] Pretty-printed sublink test expressions lose needed parentheses

Henson Choi <assam258(at)gmail(dot)com> writes:
> Agreed. The attached v2 keeps only the get_rule_expr_paren()
> change. The tests are cut down to one case for each form that needs
> parentheses, plus test expressions that need none and keep none.
> Some test expressions that need no parentheses do get them now, as
> in ((c + d) IN (SELECT 3)), which reads back as the same expression.

Okay. I merged this with the other thread about AS in
UPDATE/DELETE/MERGE, reduced the tests a bit (in particular the
behavior for UPDATE/DELETE/MERGE seems to me already fully covered
by existing tests), and pushed it.

> All of these are closed on the right, so the IN or op ANY that follows
> cannot bind into them; everything else gets parentheses. IS DOCUMENT
> is closed on the right but not on the left, so it loses its own
> parentheses when it is the right operand of another operator; that
> is handled in CF 7451.

OK, I'll look at that.

> Parentheses, on the other hand, have no shared infrastructure at all.
> What gram.y can give them directly is the precedence table. I have
> a vague idea that, if that table were generated from gram.y the way
> the node support functions are generated from the node definitions,
> and the printed forms of analyzed nodes were tied to the gram.y
> productions they print as, parentheses and keyword quoting could be
> derived mechanically.

In theory that should be do-able, but I'm worried that we might have
to more or less replicate bison to extract the data we need :-(.

Another thing to think about here is that sometimes, "extra" parens
are useful for readability even when not formally necessary,
because not everybody has all the precedence rules fully memorized.
So to some extent, ruleutil's habit of giving up and parenthesizing
for anything beyond basic arithmetic operators isn't such a bad thing.
I'm not sure what that observation leads to in terms of devising a
more-maintainable solution, but it's worth thinking about.

regards, tom lane