Re: pg_get_viewdef() produces non-round-trippable SQL for views with USING join on mismatched integer types
Richard Guo <guofenglinux@gmail.com>
From: Richard Guo <guofenglinux@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Swirl Smog Dowry <swirl-smog-dowry@duck.com>,
pgsql-bugs@lists.postgresql.org
Date: 2026-02-27T08:13:52Z
Lists: pgsql-bugs
On Fri, Feb 27, 2026 at 12:23 PM Richard Guo <guofenglinux@gmail.com> wrote: > On Fri, Feb 27, 2026 at 3:27 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > The problem is obvious after looking at parseCheckAggregates: the > > RTE_GROUP RTE is manufactured using the groupClauses list after we > > have flattened that, which we are only doing for comparison purposes; > > it shouldn't affect what goes into the parse tree. I experimented > > with just changing the order of operations, and that seems to fix it. > Right. We should keep the unmodified GROUP BY expressions in the > parse tree, and then rely on the planner to flatten the join alias > vars within them. > > +1 to the fix. I am on the fence about whether this fix is safe to back-patch to v18. I cautiously think it is safe, as it does not change the parsetree's external representation and does not require an initdb. However, this fix will only apply to newly created views. Users who have existing views affected by this bug will have to recreate them after upgrading to get the corrected pg_get_viewdef output. (really kicking myself for this.) - Richard
Commits
-
Don't flatten join alias Vars that are stored within a GROUP RTE.
- c2c1962a64b5 18.4 landed
- 98616ac18b49 19 (unreleased) landed
-
Introduce an RTE for the grouping step
- 247dea89f761 18.0 cited