Re: [PATCH] Fixed assertion issues in "pg_get_viewdef"

Thanks for your guidance, you are right, I looked at your patch
and combined it with the example to generate a new patch,
which is really better.

Thanks,
Man Zeng

------------------ Original ------------------
From: &nbsp;"Tom&nbsp;Lane"<tgl(at)sss(dot)pgh(dot)pa(dot)us&gt;;
Date: &nbsp;Wed, Nov 20, 2024 00:21 AM
To: &nbsp;"曾满"<zengman(at)halodbtech(dot)com&gt;;
Cc: &nbsp;"pgsql-hackers"<pgsql-hackers(at)lists(dot)postgresql(dot)org&gt;;
Subject: &nbsp;Re: [PATCH] Fixed assertion issues in "pg_get_viewdef"

&nbsp;
"=?utf-8?B?5pu+5ruh?=" <zengman(at)halodbtech(dot)com&gt; writes:
&gt; We can comment out the assertion that raises the exception, because I looked up the code and found that the assertion doesn't seem to make a lot
&gt; of sense here.

I looked at the git history and found that I added this assertion
in 07b4c48b6.&nbsp; Your example shows that indeed it's a thinko, but
I'm not convinced that simply removing it is the best answer.

The real point here is that we'd want to parenthesize if a "leaf"
subquery contains set operations, to ensure that the setop nesting
is represented correctly.&nbsp; Normally, a "leaf" query would not contain
any set operations, but that can happen if the leaf query also
contains WITH/ORDER BY/FOR UPDATE/LIMIT, because that stops
transformSetOperationTree from merging it into the upper
SetOperationStmt tree.&nbsp; So the assertion should have been less
"can't have setOperations here" and more "can't have setOperations
here unless there's also one of sortClause etc".

But on reflection I don't see why it needs to be an assert at all.
Let's just make nonempty setOperations another reason to force
need_paren on, as attached.

regards, tom lane