| 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
| 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 |