Re: Fix dropped object handling in pg_event_trigger_ddl_commands
От | Michael Paquier |
---|---|
Тема | Re: Fix dropped object handling in pg_event_trigger_ddl_commands |
Дата | |
Msg-id | YMLcsJrjWAYs/7SL@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Fix dropped object handling in pg_event_trigger_ddl_commands (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Fix dropped object handling in pg_event_trigger_ddl_commands
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: