On Sat, Feb 9, 2019 at 9:41 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > > On 2019-Feb-08, Tom Lane wrote: > >> Also, I came across some coding in CloneFkReferencing() that looks fishy > >> as hell: that function imagines that it can delete an existing trigger > >> with nothing more than a summary CatalogTupleDelete(). I didn't do > >> anything about that here, but if it's not broken, I'd like to see an > >> explanation why not. I added a comment complaining about the lack of > >> pg_depend cleanup, and there's also the question of whether we don't > >> need to broadcast a relcache inval for the trigger's table. > > > Oops, this is new code in 0464fdf07f69 (Jan 21st). Unless you object, > > I'll study a fix for this now, to avoid letting it appear in the minor > > next week. > > +1. The best solution would presumably be to go through the normal > object deletion mechanism; though possibly there's a reason that > won't work given you're already inside some other DDL.
Maybe: - CatalogTupleDelete(trigrel, &trigtup->t_self); + RemoveTriggerById(trgform->oid)? Thanks, Amit
