On Tue, May 3, 2022 at 2:24 PM Peter Smith <smithpb2...@gmail.com> wrote: > > On Thu, Apr 28, 2022 at 9:32 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > ... > > Another idea that occurred to me today for tables this is as follows: > > 1. Allow to mention except during create publication ... For All Tables. > > CREATE PUBLICATION pub1 FOR ALL TABLES EXCEPT TABLE t1,t2; > > 2. Allow to Reset it. This new syntax will reset all objects in the > > publications. > > Alter Publication ... RESET; > > 3. Allow to add it to an existing publication > > Alter Publication ... Add ALL TABLES [EXCEPT TABLE t1,t2]; > > > > I think it can be extended in a similar way for schema syntax as well. > > > > Consider if the user does > CREATE PUBLICATION pub1 FOR ALL TABLES EXCEPT TABLE t1,t2; > ALTER PUBLICATION pub1 ADD ALL TABLES EXCEPT t3,t4; > > What does it mean? > e.g. Is there only one exception list that is modified? Or did the ADD > ALL TABLES override all meaning of the original list? > e.g. Are we now skipping t1,t2,t3,t4, or are we now only skipping t3,t4? >
This won't be allowed. We won't allow changing ALL TABLES publication unless the user first performs RESET. This is the purpose of providing the RESET variant. > ~~~ > > Here is a similar example, where the ADD TABLE seems confusing to me > when it intersects with a prior EXCEPT > e.g. > CREATE PUBLICATION pub1 FOR ALL TABLES EXCEPT t1,t2; // ok > ALTER PUBLICATION pub1 ADD TABLE t1; ??? > > What does it mean? > e.g. Does the explicit ADD TABLE override the original exception list? > e.g. Is t1 published now or should that ALTER have caused an error? > This won't be allowed either. We don't allow to Add/Drop from All Tables publication unless the user performs a RESET. This is true even today except that we don't have a RESET syntax. > ~~ > > It feels like there are too many tricky rules when using EXCEPT with > ALTER PUBLICATION. I guess complexities can be described in the > documentation but IMO it would be better if the ALTER syntax could be > unambiguous in the first place. > Agreed. > So perhaps the rules should be more > restrictive (e.g. just disallow ALTER ... ADD any table that overlaps > the existing EXCEPT list ??) > I think the current proposal seems to be restrictive enough to avoid any tricky issues. Do you see any other problem? -- With Regards, Amit Kapila.
