Re: Fix dropped object handling in pg_event_trigger_ddl_commands - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Fix dropped object handling in pg_event_trigger_ddl_commands
Date
Msg-id YMLcsJrjWAYs/7SL@paquier.xyz
Whole thread Raw
In response to Re: Fix dropped object handling in pg_event_trigger_ddl_commands  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Fix dropped object handling in pg_event_trigger_ddl_commands
List pgsql-hackers
On Thu, Jun 10, 2021 at 05:07:28PM +0900, Michael Paquier wrote:
> 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.

I have been looking at that more this morning, and I have convinced
myself that skipping objects should work fine.  The test added at the
bottom of event_trigger.sql was making the file a bit messier though,
and there are already tests for relations when it comes to dropped
objects.  So let's do a bit of consolidation while on it with an extra
event trigger on ddl_command_end and relations on the schema evttrig.

This one already included some cases for serial columns, so that's
natural to me to extend the area for identity columns.  I have also
added a case for a serial column dropped, while on it.  The last thing
is the addition of r.object_identity from
pg_event_trigger_ddl_commands() in the data generated for the output
messages, so as the output is as complete as possible.

Regarding the back-branches, I am tempted to do nothing.  The APIs are
just not here to do the job.  On top of being an invasive change, it
took 4 years for somebody to complain on this matter, as this exists
since 10.  That's not worth the risk/cost.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: Multi-Column List Partitioning
Next
From: Amit Kapila
Date:
Subject: Re: [bug?] Missed parallel safety checks, and wrong parallel safety