On Fri, Apr 7, 2023 11:23 AM houzj.f...@fujitsu.com <houzj.f...@fujitsu.com>
wrote:
>
> On Friday, April 7, 2023 11:13 AM houzj.f...@fujitsu.com
> <houzj.f...@fujitsu.com>
> >
> > On Tuesday, April 4, 2023 7:35 PM shveta malik <shveta.ma...@gmail.com>
> > wrote:
> > >
> > > On Tue, Apr 4, 2023 at 8:43 AM houzj.f...@fujitsu.com
> > > <houzj.f...@fujitsu.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.
>
> Sorry, there was a miss when rebasing the patch which could cause the
> CFbot to fail and here is the correct patch set.
>
Hi,
Thanks for your patch. Here are some comments.
1.
I saw a problem in the following case.
create type rewritetype as (a int);
alter type rewritetype add attribute b int cascade;
For the ALTER TYPE command, the deparse result is:
ALTER TYPE public.rewritetype ADD ATTRIBUTE b pg_catalog.int4 STORAGE plain
"STORAGE" is not supported for TYPE. Besides, "CASCADE" is missed.
I think that's because in deparse_AlterRelation(), we process ALTER TYPE ADD
ATTRIBUTE the same way as ALTER TABLE ADD COLUMN. It looks we need some
modification for ALTER TYPE.
2.
in 0001 patch
+ tmp_obj2 = new_objtree_VA("CASCADE", 1,
+
"present", ObjTypeBool, subcmd->behavior);
Would it be better to use "subcmd->behavior == DROP_CASCADE" here?
Regards,
Shi Yu
