On Mon, Apr 27, 2026 at 9:06 AM shveta malik <shveta.malik@gmail.com> wrote:
>
> On Mon, Apr 27, 2026 at 9:02 AM Nisha Moond <nisha.moond412@gmail.com> wrote:
> >
> > On Fri, Apr 24, 2026 at 11:29 AM shveta malik <shveta.malik@gmail.com> wrote:
> > >
> > > > I feel just like we associate column lists and row filters directly
> > > > with each table, rather than using a mixed style at the end; we should
> > > > also allow EXCEPT to be specified alongside each schema. This would
> > > > avoid added complexity and reduce potential confusion. Thoughts?
> > >
> > > One correction: I meant, we should "only" allow EXCEPT to be
> > > specified alongside each schema.
> > >
> >
> > I kept this for user convenience to specify the EXCEPT list in one go.
> > But as you mentioned, supporting mixed style adds complexity, as
> > currently, it checks tables against all schemas in the publication
> > (not just those in the command).
> >
> > In further testing, I also noticed below confusing behavior due to
> > allowed mixed style -
> >
> > CREATE PUBLICATION pub FOR TABLES IN SCHEMA s1;
> > ALTER PUBLICATION pub ADD TABLES IN SCHEMA s2 EXCEPT (TABLE s1.t1);
> > -- here, s1.t1 is allowed in EXCEPT because s1 is already part of the
> > publication, even though it’s not in the current command.
>
> This case seems further confusing.
>
> >
> > Let me make the changes to restrict the mixed style. Will share the
> > updated patch soon.
> >
>
> Yes, that will be better approach.
>
Please find the attached patches incorporating the above suggestion.
The EXCEPT clause now accepts tables only of its adjacent schema and
mixed style is not allowed.
Few examples :
CREATE PUBLICATION pub FOR TABLES IN SCHEMA s1 EXCEPT (TABLE t1), s2
EXCEPT (TABLE t1);
-- both s1.t1 and s2.t1 will be added in except list
CREATE PUBLICATION pub FOR TABLES IN SCHEMA s1, s2 EXCEPT (TABLE s1.t1, s2.t1);
-- ERROR: table "s1.t1" in EXCEPT clause does not belong to schema "s2"
--
Thanks,
Nisha
