| 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: | Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values |
| Date: | 2023-02-23 23:20:05 |
| Message-ID: | CAEZATCUo-GCtup4_ve89pp+3XTBirqppi8fYv16J+uxnAcA4AQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Thu, 23 Feb 2023 at 21:50, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> It looks to me like the rewriter is failing to set the rte->lateral flag
> on the sub-select, or maybe the fault is even earlier in the parser.
>
> Arguably, the user should have written LATERAL on that sub-select in
> the first place, but we probably can't start enforcing that ex post
> facto. We'll have to do something that causes NEW (and OLD?) references
> in sub-selects to generate a LATERAL marking silently.
>
Yeah, my first thought was to try to fix it up in the rewriter, so
that it can deal with any existing stored rules.
Doing the attached fixes the reported issue, and all variants of it
that I could come up with, but I'm not entirely sure whether it needs
to be concerned about other rtekinds.
Regards,
Dean
| Attachment | Content-Type | Size |
|---|---|---|
| add-lateral-markers.patch | text/x-patch | 1.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2023-02-23 23:36:36 | Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash |
| Previous Message | PG Bug reporting form | 2023-02-23 22:33:30 | BUG #17806: PostgreSQL 13.10 returns "CREATE DATABASE cannot be executed within a pipeline" |