Re: Fix dropped object handling in pg_event_trigger_ddl_commands

On Wed, Jun 09, 2021 at 09:55:08AM -0400, Alvaro Herrera wrote:
> I'm not sure if we can reasonably implement a fix for older releases.
> I mean, it's a relatively easy test: do a syscache search for the object
> or a catalog indexscan (easy to do with get_object_property_data-based
> API), and if the object is gone, skip getObjectTypeDescription and
> getObjectIdentity. But maybe this is too much code to add to stable
> releases ...

Except that these syscache lookups need to be done on an object-type
basis, which is basically what getObjectDescription() & friends now do
where the logic makes sure that we have a correct objectId <-> cacheId
mapping for the syscache lookups. So that would be roughly copying
into event_trigger.c what objectaddress.c does now, but for the back
branches. It would be better to just backport the changes to support
missing_ok in objectaddress.c if we go down this road, but the
invasiveness makes that much more complicated.

Another thing is that ATExecDropIdentity() does performDeletion() by
using PERFORM_DELETION_INTERNAL, which does not feed the dropped
sequence to pg_event_trigger_dropped_objects(). That feels
inconsistent with CREATE TABLE GENERATED that would feed to event
triggers the CREATE SEQUENCE and ALTER SEQUENCE commands, as well as
ALTER TABLE SET DATA TYPE on a generated column that feeds an internal
ALTER SEQUENCE.

An extra idea we could consider, as the drop events are logged before
the other ALTER TABLE subcommands, is to look at the event triggers
registered when the generated sequence is dropped and to erase from
existence any previous events associated to it, but that would make
the logic weak as hell. In all this stuff, simply ignoring the
objects still sounds like a fair and simple course of action to take
if they are gone at the time an event trigger checks after them within
pg_event_trigger_ddl_commands(). Now, this approach makes my spider
sense tingle.
--
Michael