RE: Collect ObjectAddress for ATTACH DETACH PARTITION to use in event trigger

From: "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com>
To: "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: Collect ObjectAddress for ATTACH DETACH PARTITION to use in event trigger
Date: 2022-07-15 09:53:24
Message-ID: TYAPR01MB5866683E55284C28BEFA5D7BF58B9@TYAPR01MB5866.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dear Hou-san,

> Thanks for having a look. It was a bit difficult to add a test for this.
> Because we currently don't have a user function which can return these
> collected ObjectAddresses for ALTER TABLE. And It seems we don't have tests for
> already collected ObjectAddresses as well :(
> The collected ObjectAddresses is in
> "currentEventTriggerState->currentCommand->d.alterTable.subcmds.address" while
> the public function pg_event_trigger_ddl_commands doesn't return these
> information. It can only be used in user defined event trigger function (C
> code).

Thanks for explaining. I did not know the reason why the test is not in event_trigger.sql.

> If we want to add some tests for both already existed and newly added
> ObjectAddresses, we might need to add some test codes in test_ddl_deparse.c.
> What do you think ?

I thought tests for ObjectAddresses should be added to test_ddl_deparse.c, but
it might be bigger because there were many ATExecXXX() functions.
I thought they could be added separately in another thread or patch.

Best Regards,
Hayato Kuroda
FUJITSU LIMITED

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2022-07-15 10:58:44 Re: standby recovery fails (tablespace related) (tentative patch and discussion)
Previous Message Matthias van de Meent 2022-07-15 09:25:54 Re: Non-replayable WAL records through overflows and >MaxAllocSize lengths