Re: BUG #19632: RULE rewriting crashes with XX000 when RETURNING old/new references a system column

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
Cc: hackerzheng666(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19632: RULE rewriting crashes with XX000 when RETURNING old/new references a system column
Date: 2026-08-19 23:37:05
Message-ID: aoY-IVnSckypD-O-@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Aug 19, 2026 at 11:56:19AM +0100, Zsolt Parragi wrote:
> Hello
>
> This also seems reproducible on PG 18.
>
> I think there could be some corner-cases where supporting this would
> be useful, for example SQLAlchemy supports locking via xmin[1], and a
> soft delete rule (ON DELETE DO INSTEAD UPDATE ... SET deleted=true)
> could break that.
>
> We could support something like this with a new syntax perhaps?

Target list replacements have never coped with negative attnums in the
rewrite paths, as far as I can see.

> CREATE RULE ... DO INSTEAD ... RETURNING * WITH SYSTEM COLUMNS (xmin
> AS t.xmin ....);

FWIW, I tend to see rules as relics of the past. Triggers are for one
more useful in modern systems, so I cannot really get excited with an
extension of the grammar to support an edge case that has, as far as I
know, never worked since we support RETURNING.

> However, that would be a new feature. The safe and easy choice (at
> least for 18/19) seems to be reporting a proper error message.

An error message sounds like a protection good enough for me. Whether
someone is motivated to support such cases is a different question,
but IMO we may be closer with removing support for rules than trying
to extend it.
--
Michael

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2026-08-20 00:40:58 Re: BUG #19627: 32,768 trigger arguments wrap `tgnargs` and are silently lost at runtime
Previous Message Fujii Masao 2026-08-19 17:57:53 Re: BUG #19598: pg_waldump: -s/-e accept out-of-range WAL locations and silently use the low 32 bits