RE: Collect ObjectAddress for ATTACH DETACH PARTITION to use in event trigger - Mailing list pgsql-hackers

From houzj.fnst@fujitsu.com
Subject RE: Collect ObjectAddress for ATTACH DETACH PARTITION to use in event trigger
Date
Msg-id OS0PR01MB5716D110FDDBD93DFFBFFD58948B9@OS0PR01MB5716.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Collect ObjectAddress for ATTACH DETACH PARTITION to use in event trigger  (Michael Paquier <michael@paquier.xyz>)
Responses RE: Collect ObjectAddress for ATTACH DETACH PARTITION to use in event trigger
Re: Collect ObjectAddress for ATTACH DETACH PARTITION to use in event trigger
List pgsql-hackers
On Friday, July 15, 2022 11:41 AM Michael Paquier <michael@paquier.xyz> wrote:

Hi,
>
> On Fri, Jul 15, 2022 at 03:21:30AM +0000, kuroda.hayato@fujitsu.com wrote:
> > Sounds good. I grepped ATExecXXX() functions called in ATExecCmd(),
> > and I confirmed that all returned values have been collected except them.
> >
> > While checking test code test about EVENT TRIGGER, I found there were
> > no tests related with partitions in that.
> > How about adding them?
>
> Agreed.  It would be good to track down what changes once those
> ObjectAddresses are collected.

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).

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 ?

Best regards,
Hou zhijie



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: POC: GROUP BY optimization
Next
From: Erik Rijkers
Date:
Subject: Re: SQL/JSON documentation JSON_TABLE