| From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Swirl Smog Dowry <swirl-smog-dowry(at)duck(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pg_get_viewdef() produces non-round-trippable SQL for views with USING join on mismatched integer types |
| Date: | 2026-02-27 03:23:14 |
| Message-ID: | CAMbWs4_FLicDsNpotM0uEFkeveJ+gULe4VP0PyJ=FVsD9iYCGA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Fri, Feb 27, 2026 at 3:27 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
> The lack of any effect on check-world shows we need more test cases
> here ...
How about this new test case in the attached (parse_agg.c untouched)?
- Richard
| Attachment | Content-Type | Size |
|---|---|---|
| wip-preserve-join-aliases-in-RTE_GROUP.patch | application/octet-stream | 3.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | yafei wu | 2026-02-27 07:44:12 | Re: BUG #19419: Cannot create custom functions using python3u |
| Previous Message | David G. Johnston | 2026-02-27 01:20:23 | Re: BUG #19417: '\dD' fails to list user-defined domains that shadow built-in type names (e.g., 'numeric') |