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 OS0PR01MB5716B3CEFFD160FDA40F7D4A94989@OS0PR01MB5716.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Re: Collect ObjectAddress for ATTACH DETACH PARTITION to use in event trigger  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Collect ObjectAddress for ATTACH DETACH PARTITION to use in event trigger  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On Saturday, July 30, 2022 3:15 PM Michael Paquier <michael@paquier.xyz> wrote:
> On Tue, Jul 26, 2022 at 01:00:41PM +0000, houzj.fnst@fujitsu.com wrote:
> > Thanks for the suggestion. I have removed the default and found some
> > missed subcommands in 0003 patch. Attach the new version patch here
> > (The 0001 and 0002 is unchanged).
>
> I have reviewed what you have here, and I found that the change is too timid,
> with a coverage of 32% for test_ddl_deparse.  Attached is an updated patch, that
> provides coverage for the most obvious cases I could see in tablecmds.c,
> bringing the coverage to 64% here.

Thanks ! the patch looks better now.

> Some cases are straight-forward, like the four cases for RLS or the three
> subcases for RelOptions (where we'd better return an address even if doing
> doing for the replace case).

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.

Best regards,
Hou Zhijie



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Julien Rouhaud
Дата:
Сообщение: Re: [PATCH] Add extra statistics to explain for Nested Loop
Следующее
От: "houzj.fnst@fujitsu.com"
Дата:
Сообщение: RE: Functions 'is_publishable_class' and 'is_publishable_relation' should stay together.