Sorry, away from work past few days.
On Wed, Jan 1, 2020 at 4:48 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> On 2019-Dec-27, Alvaro Herrera wrote:
> > One thing I just realized is that in next minors' release notes we
> > should publish a recipe to fix catalogs for existing databases, unless
> > we go for a fix that doesn't require changing the catalogs -- I don't
> > know what that would be, though, but maybe it would not be totally
> > insane to clone even internal triggers in the cases that matter.
On second thought, I agree that not having to have to fix catalog
state for existing users would be good.
> So, the more I thought about this, the more it seemed that marking those
> triggers as not internal was the wrong thing to do. So I instead made
> it clone the internal triggers that seem to matter. This fixes the
> originally reported problem, and passes the test case I propose. Also,, away
> pg_dump continues to work unchanged, and existing database don't need
> tweaking (excepting those that might already be missing triggers).
0002 seems fine as a solution although some comments:
+/*
+ * doesTriggerDependOnAnotherTrigger
+ * Checks pg_depend for what the name says
+ *
+ * This is an ugly hack to cope with a catalog deficiency.
+ * Keep away from children. Do not stare with naked eyes. Do not propagate.
+ */
+static bool
+doesTriggerDependOnAnotherTrigger(Oid trigger_oid)
Instead of making this too generic sounding, would it be better to
name this to make clear what hack this is part of, say,
isPartitionTrigger?
> It would be better to fix master afterwards, by adding a
> pg_trigger.trgparentid column, which seems like it would be a better
> answer going forward.
Agreed.
Thanks,
Amit