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

[zengman]

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"<t...@sss.pgh.pa.us&gt;;
Date: &nbsp;Wed, Nov 20, 2024 00:21 AM
To: &nbsp;"????"<zeng...@halodbtech.com&gt;; 
Cc: &nbsp;"pgsql-hackers"<pgsql-hackers@lists.postgresql.org&gt;; 
Subject: &nbsp;Re: [PATCH] Fixed assertion issues in "pg_get_viewdef"

&nbsp;
"=?utf-8?B?5pu+5ruh?=" <zeng...@halodbtech.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

v3-fix-incorrect-assertion.patch
Description: Binary data