| From: | Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com> |
|---|---|
| To: | SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com> |
| Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: SQL:2011 Application Time Update & Delete |
| Date: | 2026-04-15 17:30:21 |
| Message-ID: | CA+renyVkfsrNNnYqLpf_g3mDV31KLFXAw-RRVmyLb7TcBLUO7A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Apr 14, 2026 at 10:34 PM Paul A Jungwirth
<pj(at)illuminatedcomputing(dot)com> wrote:
>
> > A BEFORE UPDATE trigger that modifies the range column creates overlapping rows. The trigger widening the range doesn't affect leftover computation, which uses the original FPO bounds. Result: updated row overlaps both leftovers.
>
> I'm working on a fix for this. It's not quite ready, but I can finish
> it in the morning. . . .
Actually I think the proper behavior here is to raise an error. We
forbid setting the application-time column when using FOR PORTION OF
(per the standard), so why should we allow a BEFORE trigger to set it?
I think it has the same inconsistency problems. We could support it,
but then why not support both?
Assuming we want to raise an error, I think the best way is to check
the tuple in ExecForPortionOfLeftovers to see if a trigger has
modified it, and in that case raise an error. What do you think?
Yours,
--
Paul ~{:-)
pj(at)illuminatedcomputing(dot)com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Melanie Plageman | 2026-04-15 17:56:50 | Re: First draft of PG 19 release notes |
| Previous Message | Jacob Champion | 2026-04-15 17:21:34 | Re: First draft of PG 19 release notes |