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
signature.asc
Description: PGP signature
