From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: a misbehavior of partition row movement (?) |
Date: | 2020-10-03 02:42:21 |
Message-ID: | CA+HiwqHnJtavV-4L+wEXK02meAXqk2Nx11Lq8QF5=1cf=T9bdw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Oct 2, 2020 at 11:32 PM David G. Johnston
<david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> On Friday, October 2, 2020, Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
>>
>>
>> Reporter on that thread says that the last update should have failed
>> and I don't quite see a workable alternative to that.
>
>
> To be clear the OP would rather have it just work, the same as the non-row-movement version. Maybe insert the new row first, execute the on update trigger chained from the old row, then delete the old row?
I was thinking yesterday about making it just work, but considering
the changes that would need to be made to how the underlying triggers
fire, it does not seem we would be able to back-port the solution.
--
Amit Langote
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2020-10-03 02:55:45 | Re: "cert" + clientcert=verify-ca in pg_hba.conf? |
Previous Message | Andy Fan | 2020-10-03 02:05:59 | Re: Improve choose_custom_plan for initial partition prune case |