On Sat, Oct 3, 2020 at 8:15 PM Tomas Vondra <tomas.von...@2ndquadrant.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.g.johns...@gmail.com> wrote: > >> On Friday, October 2, 2020, Amit Langote <amitlangot...@gmail.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
