RE: Support logical replication of DDLs

On Friday, April 7, 2023 11:23 AMhouzj(dot)fnst(at)fujitsu(dot)com <houzj(dot)fnst(at)fujitsu(dot)com> wrote:
>
> On Friday, April 7, 2023 11:13 AM houzj(dot)fnst(at)fujitsu(dot)com
> <houzj(dot)fnst(at)fujitsu(dot)com>
> >
> > On Tuesday, April 4, 2023 7:35 PM shveta malik
> > <shveta(dot)malik(at)gmail(dot)com>
> > wrote:
> > >
> > > On Tue, Apr 4, 2023 at 8:43 AM houzj(dot)fnst(at)fujitsu(dot)com
> > > <houzj(dot)fnst(at)fujitsu(dot)com> wrote:
> > >
> > > > Attach the new version patch set which did the following changes:
> > > >
> > >
> > > Hello,
> > >
> > > I tried below:
> > > pubnew=# ALTER PUBLICATION mypub2 SET (ddl = 'table'); ALTER
> > > PUBLICATION
> > >
> > > pubnew=# \dRp+
> > > Publication mypub2 Owner |
> > > All tables
> > > | All DDLs | Table DDLs |
> > > --------+------------+----------+------------+---------
> > > shveta | t | f | f
> > > (1 row)
> > >
> > > I still see 'Table DDLs' as false and ddl replication did not work for this case.
> >
> > Thanks for reporting.
> >
> > Attach the new version patch which include the following changes:
> > * Fix the above bug for ALTER PUBLICATION SET.
> > * Modify the corresponding event trigger when user execute ALTER
> > PUBLICATION SET to change the ddl option.
> > * Fix a miss in pg_dump's code which causes CFbot failure.
> > * Rebase the patch due to recent commit 4826759.

Another thing I find might need to be improved is about the pg_dump handling of
the built-in event trigger. Currently, we skip dumping the event trigger which
are used for ddl replication based on the trigger names(pg_deparse_trig_%s_%u),
because they will be created along with create publication command. Referring
to other built-in triggers(foreign key trigger), it has a tgisinternal catalog
column which can be used to skip the dump for them.

Personally, I think we can follow this style and add a isinternal column to
pg_event_trigger and use it to skip the dump. This could also save some
handling code in pg_dump.

Best Regards,
Hou zj