RE: Collect ObjectAddress for ATTACH DETACH PARTITION to use in event trigger
От | houzj.fnst@fujitsu.com |
---|---|
Тема | RE: Collect ObjectAddress for ATTACH DETACH PARTITION to use in event trigger |
Дата | |
Msg-id | OS0PR01MB5716078F452F8EF11D29807F949A9@OS0PR01MB5716.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: Collect ObjectAddress for ATTACH DETACH PARTITION to use in event trigger (Michael Paquier <michael@paquier.xyz>) |
Список | pgsql-hackers |
On Sunday, July 31, 2022 12:12 PM Michael Paquier <michael@paquier.xyz> wrote: > > On Sat, Jul 30, 2022 at 01:13:52PM +0000, houzj.fnst@fujitsu.com wrote: > > I am not against returning the objaddr for cases related to RLS and > RelOption. > > But just to confirm, do you have a use case to use the returned > > address(relation itself) for RLS or RelOptions in event trigger ? I > > asked this because when I tried to deparse the subcommand of ALTER > > TABLE. It seems enough to use the information inside the parse tree to > deparse the RLS and RelOptions related subcommands. > > You are right here, there is little point in returning the relation itself. I have > removed these modifications, added a couple of extra commands for some > extra coverage, and applied all that. I have finished by splitting the extension > of test_ddl_deparse/ and the addition of ObjectAddress for the attach/detach > into their own commit, mainly for clarity. Thanks! Best regards, Hou Zhijie
В списке pgsql-hackers по дате отправления: