| From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
|---|---|
| To: | Marko Grujic <marko(dot)grujic(at)enterprisedb(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Marko Grujic <markoog(at)gmail(dot)com> |
| Subject: | Re: [PATCH v1] [BUG #19516] Skip whole-row projection shortcut for OLD/NEW returning type |
| Date: | 2026-06-10 12:47:32 |
| Message-ID: | CAEZATCXTptenJ3Henx0JUHZ0oZe3+mvVHsuiNmjUF3s8=GSmSQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 10 Jun 2026 at 13:23, Marko Grujic
<marko(dot)grujic(at)enterprisedb(dot)com> wrote:
>
> Agreed that this is a better solution than the present patch.
>
> That said what do you think about retrofitting GetNSItemByRangeTablePosn to accept VarReturningType too (other callers can pass VAR_RETURNING_DEFAULT)?
I don't like changing GetNSItemByRangeTablePosn() in back-branches
because some external code might be using it, though I didn't find any
examples on PGXN.
Some users of GetNSItemByRangeTablePosn() look fine, so there's no
need to change them -- for example, the MERGE parsing code, which
isn't starting from a Var, and isn't processing something that could
be in a RETURNING list.
OTOH, I think ExpandRowReference() does need updating -- at least the
comment suggests that (old.*).* will go through it, rather than
ParseComplexProjection(), so wouldn't be fixed by your original patch.
The one I'm unsure about is coerce_record_to_complex(). I can't manage
to come up with an example that breaks it, but it certainly looks like
it should be updated.
Regards,
Dean
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ayush Tiwari | 2026-06-10 12:48:59 | Re: PG19 FK fast path: OOB write and missed FK checks during batched |
| Previous Message | Bertrand Drouvot | 2026-06-10 12:31:04 | Re: Avoid orphaned objects dependencies, take 3 |