Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values - Mailing list pgsql-bugs

From Dean Rasheed
Subject Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values
Date
Msg-id CAEZATCUo-GCtup4_ve89pp+3XTBirqppi8fYv16J+uxnAcA4AQ@mail.gmail.com
Whole thread Raw
In response to Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #17803: Rule "ALSO INSERT ... SELECT ..." fails to substitute default values  (Dean Rasheed <dean.a.rasheed@gmail.com>)
List pgsql-bugs
On Thu, 23 Feb 2023 at 21:50, Tom Lane <tgl@sss.pgh.pa.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

pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #17806: PostgreSQL 13.10 returns "CREATE DATABASE cannot be executed within a pipeline"
Next
From: Andres Freund
Date:
Subject: Re: BUG #17800: ON CONFLICT DO UPDATE fails to detect incompatible fields that leads to a server crash