Re: Support EXCEPT for TABLES IN SCHEMA publications

From: shveta malik <shveta(dot)malik(at)gmail(dot)com>
To: Peter Smith <smithpb2250(at)gmail(dot)com>
Cc: vignesh C <vignesh21(at)gmail(dot)com>, Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, shveta malik <shveta(dot)malik(at)gmail(dot)com>
Subject: Re: Support EXCEPT for TABLES IN SCHEMA publications
Date: 2026-08-14 05:58:50
Message-ID: CAJpy0uAg-pMq37fBd7SAyGVwCCPyG1pGQAOEDkMU7kJuLUN3KQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 13, 2026 at 12:52 PM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>
>
> 2b.
> /In the partition case/For partitions/
>
> AFAICT this case is referring to something like: "FOR TABLE part,
> TABLES IN SCHEMA EXCEPT (part_root)"
>
> But, isn't that just a variation of the 1st case issue? e.g. where
> table "part" is not yet visible for later lookup of "root", then you
> wont be able to check integrity of the partition tree regardless of
> the up/down traversal logic, so I wasn't sure why this 2nd case was
> separately mentioned at all.

The second point is different from the first. Consider this case:

CREATE PUBLICATION pub1 FOR s2.tab_part;
ALTER PUBLICATION pub1 ADD TABLES IN SCHEMA s2 EXCEPT (TABLE tab_root);

Here, the partition entry in pg_publication_rel is visible to the
second command in publication_add_relation() and in
check_publication_add_relation(). But the checks there are not
sufficient to identify the error. If we try to detect the error while
adding tab_root in publication_add_relation(),
we would need to perform a full descendant search to determine whether
any of its descendants are already present in pg_publication_rel. This
downward traversal is what we are trying to avoid in
publication_add_relation(). Geenrally we rely on ancestor-lookup and
we want to stick to that instead of introducing a new logic.
Thus the logic in CheckExceptNotInTableList() is needed here. It reads
all explicitly added entries from pg_publication_rel, looks up their
ancestors to find the root, and checks the EXCEPT entries against that
root.

This is my understanding, let's wait for Nisha's comments as well.

I feel the comment about the second case should be moved to patch002,
where it actually makes sense and explains why it is needed even after
point 1.

thanks
Shveta

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2026-08-14 06:16:24 Re: Allow a condition string in an injection point
Previous Message Bertrand Drouvot 2026-08-14 05:47:06 Re: pg_control_checkpoint(): add "data_checksum_version" (Pg19)?