| 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
| 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 |