| 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 11:54:06 |
| Message-ID: | CAEZATCVhtDNJYXaq_cWLE9RCUQT6vA9z04Djv3P9NY-_TQ0Cdg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 10 Jun 2026 at 11:48, Marko Grujic
<marko(dot)grujic(at)enterprisedb(dot)com> wrote:
>
> Hi, submitting a patch for bug #19516 (held in moderation queue atm).
>
> Looks like the root cause is that the shortcut taken in ParseComplexProjection
> loses the `varreturningtype` flag, causing it to default to `VAR_RETURNING_DEFAULT`.
>
> Consequently, the default RETURNING behavior is applied, which is strictly wrong
> when a user typed (old).col on INSERT/UPDATE or (new).col on DELETE.
>
> To fix this simply skip the shortcut when varreturningtype is set to VAR_RETURNING_OLD/VAR_RETURNING_NEW.
Nice catch!
I actually think that the root cause of the problem is
ParseComplexProjection()'s use of GetNSItemByRangeTablePosn(), which
returns the wrong nsitem because it only compares varno and
varlevelsup, not varreturningtype.
So I think a better solution would be to add a new function
GetNSItemByVar(), similar to GetNSItemByRangeTablePosn() except that
it would take a Var and return the matching nsitem, taking into
account varreturningtype. Then ParseComplexProjection() could use that
to return a Var with varreturningtype set correctly.
This makes me wonder if there are any other users of
GetNSItemByRangeTablePosn() that have a similar problem.
Regards,
Dean
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Japin Li | 2026-06-10 11:58:14 | Re: Fix md5_password_warnings for role/database settings |
| Previous Message | solai v | 2026-06-10 11:41:36 | Re: problems with toast.* reloptions |