Re: Fix dropped object handling in pg_event_trigger_ddl_commands

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Sven Klemm <sven(at)timescale(dot)com>
Subject: Re: Fix dropped object handling in pg_event_trigger_ddl_commands
Date: 2021-06-11 03:46:56
Message-ID: YMLcsJrjWAYs/7SL@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
altertab-eventtrigger-v3.patch text/x-diff 10.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-06-11 04:13:23 Re: [bug?] Missed parallel safety checks, and wrong parallel safety
Previous Message Amit Langote 2021-06-11 03:37:54 Re: Multi-Column List Partitioning