On Saturday, July 30, 2022 3:15 PM Michael Paquier <mich...@paquier.xyz> wrote: > On Tue, Jul 26, 2022 at 01:00:41PM +0000, houzj.f...@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
