| From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Bernice Southey <bernice(dot)southey(at)gmail(dot)com>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Second RewriteQuery complains about first RewriteQuery in edge case |
| Date: | 2025-11-27 19:35:28 |
| Message-ID: | CAEZATCWmpX00t3014D71j_Zr-yh-vs7Utwn1Bbb1q7Sdg58mnQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 27 Nov 2025 at 17:55, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
>
> On Thu, 27 Nov 2025 at 16:55, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >
> > I do think there's another way we could attack it. Similarly
> > to the way VALUES RTEs are either processed or skipped by
> > checking the rangetable length, we could pass down the length
> > of the outer query's cteList, and assume that the last N entries
> > in a product query's cteList have already been processed.
> > (Last N not first N because of the order in which the lists are
> > concatenated at line 596.) Maybe that's too fragile, but the
> > approach seems to have worked all right for VALUES.
>
Here's an update, doing it that way. It does appear somewhat neater.
Regards,
Dean
| Attachment | Content-Type | Size |
|---|---|---|
| v4-avoid-rewriting-data-modifying-CTEs-more-than-once.patch | text/x-patch | 4.8 KB |
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Mihail Nikalayeu | 2025-11-27 18:59:55 | Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements |