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

From Amit Kapila
Subject Re: Collect ObjectAddress for ATTACH DETACH PARTITION to use in event trigger
Date
Msg-id CAA4eK1KiQeHEmORj=r6ERy4d0q=sG4Hs=LfXNUTe+qdrvhoVuw@mail.gmail.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
List pgsql-hackers
On Sat, Jul 23, 2022 at 4:28 PM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Sat, Jul 23, 2022 at 05:44:28PM +0900, Michael Paquier wrote:
> > Changing get_altertable_subcmdtypes() to return a set of rows made of
> > (subcommand, object description) is what I actually meant upthread as
> > it feels natural given a CollectedCommand in input, and as
> > pg_event_trigger_ddl_commands() only gives access to a set of
> > CollectedCommands.  This is also a test module so
> > there is no issue in changing the existing function definitions.
> >
> > But your point would be to have a new function that takes in input a
> > CollectedATSubcmd, returning back the object address or its
> > description?  How would you make sure that a subcommand maps to a
> > correct object address?
>
> FWIW, I was thinking about something among the lines of 0002 on top of
> Hou's patch.
>

What I intended to say is similar to what you have done in the patch
but in a new function. OTOH, your point that it is okay to change
function signature/name in the test module seems reasonable to me.

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Refactor to make use of a common function for GetSubscriptionRelations and GetSubscriptionNotReadyRelations.
Next
From: Nathan Bossart
Date:
Subject: Re: Unprivileged user can induce crash by using an SUSET param in PGOPTIONS