Re: a misbehavior of partition row movement (?)

On Sat, Oct 3, 2020 at 8:15 PM Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote
> On Sat, Oct 03, 2020 at 11:42:21AM +0900, Amit Langote wrote:
> >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.
> >
>
> I think we need to differentiate between master and backbranches. IMO we
> should try to make it "just work" in master, and the amount of code
> should not be an issue there I think (no opinion on whether insert and
> update trigger is the way to go). For backbranches we may need to do
> something less intrusive, of course.

Sure, that makes sense. I will try making a patch for HEAD to make it
just work unless someone beats me to it.

--
Amit Langote
EDB: http://www.enterprisedb.com