Re: DETACH PARTITION and FOR EACH ROW triggers on partitioned tables - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: DETACH PARTITION and FOR EACH ROW triggers on partitioned tables
Date
Msg-id 20200420230406.GA27302@alvherre.pgsql
Whole thread Raw
In response to Re: DETACH PARTITION and FOR EACH ROW triggers on partitioned tables  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: DETACH PARTITION and FOR EACH ROW triggers on partitioned tables  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
> +            deleteDependencyRecordsFor(TriggerRelationId,
> +                    pg_trigger->oid,
> +                    false);
> +            deleteDependencyRecordsFor(RelationRelationId,
> +                    pg_trigger->oid,
> +                    false);
> +
> +            CommandCounterIncrement();
> +            ObjectAddressSet(object, TriggerRelationId, pg_trigger->oid);
> +            performDeletion(&object, DROP_RESTRICT, PERFORM_DELETION_INTERNAL);
> +        }
> +
> +        systable_endscan(scan);
> +        table_close(tgrel, RowExclusiveLock);
> +    }

Two small issues here.  First, your second call to
deleteDependencyRecordsFor did nothing, because your first call deleted
all the dependency records.  I changed that to two
deleteDependencyRecordsForClass() calls, that actually do what you
intended.

The other is that instead of deleting each trigger, we can accumulate
them to delete with a single performMultipleDeletions call; this also
means we get to do CommandCounterIncrement just once.

v6 fixes those things and AFAICS is ready to push.

I haven't reviewed your 0002 carefully, but (as inventor of the "TABLE
t" marker for FK constraints) I agree with Amit that we should imitate
that instead of coming up with a new way to show it.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Poll: are people okay with function/operator table redesign?
Next
From: Alexander Korotkov
Date:
Subject: Fix for pg_statio_all_tables