Re: [PATCH] Fixed assertion issues in "pg_get_viewdef"
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: 曾满 <zengman@halodbtech.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2024-11-19T16:21:33Z
Lists: pgsql-hackers
Attachments
- v2-fix-incorrect-assertion.patch (text/x-diff) patch v2
"=?utf-8?B?5pu+5ruh?=" <zengman@halodbtech.com> writes: > 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 > of sense here. I looked at the git history and found that I added this assertion in 07b4c48b6. 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. 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. 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
Commits
-
Avoid assertion failure if a setop leaf query contains setops.
- fea81aee83b5 17.3 landed
- fe084039e482 16.7 landed
- 9b9689e26cb6 15.11 landed
- 94131cd53c15 18.0 landed
- 630520c22fbb 13.19 landed
- 3eb26524ca35 14.16 landed