Re: Support EXCEPT for TABLES IN SCHEMA publications - Mailing list pgsql-hackers

From Nisha Moond
Subject Re: Support EXCEPT for TABLES IN SCHEMA publications
Date
Msg-id CABdArM4-qUkbrpjVMOqjq3TJqddzBhWDJQsATyZHHaMTp-MdEA@mail.gmail.com
Whole thread
In response to Re: Support EXCEPT for TABLES IN SCHEMA publications  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Thu, Jul 2, 2026 at 2:34 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Wed, Jul 1, 2026 at 3:54 PM shveta malik <shveta.malik@gmail.com> wrote:
> >
> > On Wed, Jul 1, 2026 at 3:42 PM Nisha Moond <nisha.moond412@gmail.com> wrote:
> > >
> > > During tests, I found one behavior that needs discussion:
> > >
> > > Consider a partition hierarchy where the root table is in schema s2, a
> > > child partition is in schema s1, and the publication includes both
> > > schemas but excludes only the root table.
> >
> > This is the exact scenario I had in mind when reviewing
> > 'get_rel_sync_entry-->GetTopMostAncestorInPublication' flow, thus I
> > suggested adding comments about intentionally fetching the 'Exclude
> > list' only for the Root. I was about to test it in my next review
> > cycle.
> >
> > The first thought is that if root is excluded, the partition should
> > also be excluded to maintain consistency with the 'ALL TABLES Except
> > ROOT' behaviour. But then it needs to be documented too.
> >
>
> +1. It is good to be consistent here with similar ALL TABLES case.
> BTW, as we can't exclude the child table explicitly, this anyway seems
> like the only option because otherwise, users won't have any way to
> exclude the child table.
>

I've updated the related comments in v18 and also updated the CREATE
PUBLICATION docs to clarify this behavior.

--
Thanks,
Nisha



pgsql-hackers by date:

Previous
From: Nisha Moond
Date:
Subject: Re: Support EXCEPT for TABLES IN SCHEMA publications
Next
From: Antonin Houska
Date:
Subject: Re: REPACK CONCURRENTLY fails on tables with generated columns