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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: assam258(at)gmail(dot)com
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [DEPARSE] Pretty-printed sublink test expressions lose needed parentheses
Date: 2026-10-18 15:45:56
Message-ID: 249661.1792338356@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Henson Choi <assam258(at)gmail(dot)com> 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-10-18 15:49:08 Re: [DEPARSE] An alias named 'set' on an UPDATE, DELETE or MERGE target does not read back
Previous Message Greg Burd 2026-10-18 15:30:47 ILIKE '%' never matches a non-ASCII byte in single-byte C-ctype databases