Re: Skipping schema changes in publication

On Fri, Jan 30, 2026 at 1:46 PM Peter Smith <smithpb2250@gmail.com> wrote:
>
> Hi Vignesh.
>
> Some review comments for v38-0001.
>
> ======
>
> 1. General. Patch structure
>
> This patch set structure seems muddled to me; I think patch 0001
> requires proper handling for EXCEPT (partitions), otherwise, it cannot
> be independently committed.
>
> It's my understanding that the goal is to try approach #1, but if that
> proves too difficult, then the fallback would be approach #3. Yet
> AFAICT this patch 0001 is neither -- I have no idea anymore what patch
> 0001 does for partitions; IIUC it looks like just old partition logic
> from a few versions back (???).
>
> Personally, I felt it would be better to combine 0001 + 0002 (approach
> #3), then 0002 would be a patch that *replaces* approach #3 logic with
> approach #1 logic. That way, 0001 is self-contained, and 0002 is an
> evolution of the feature.
>

I agree that the current patch structure is hard to follow and doesn’t
add much value, since patch001 isn’t aligned with a specific approach.
How about this patch structure:

patch001: Implement EXCEPT syntax and CREATE PUBLICATION changes. This
includes all changes required to correctly populate
pg_publication_tables and pg_publication_rel.

Expectation for patch001:
When this patch is applied on its own, CREATE PUBLICATION command with
the EXCEPT clause should work, and the appropriate entries should
appear in pg_publication_tables/pg_publication_rel with the except
flag set correctly. No publishing expected in this patch.

patch002: Enable publishing and subscription support.
All changes required to make subscriptions work should go here, including:
--table sync and other subscriber-side changes
--pgoutput logic to determine which tables are published

Expectation for patch002:
Changes should be published and replicated correctly to the subscriber.

patch003: pg_dump, tests, documentation, etc.

All of the above changes/patches are intended to support Approach001.

Approach003 has a limitation in that it allows 'only' ROOT table to be
specified in the EXCEPT clause. If tab_root is listed in EXCEPT and a
user later attempts to attach it as a partition of another table
using:
'ALTER TABLE root ATTACH PARTITION tab_root', we would need to block
the ATTACH PARTITION command. Given this, we should first try to
implement Approach001 and evaluate its feasibility. If it turns out to
be impractical,
we can fall back to Approach003 or consider other alternatives. For
now, the Approach003 patch can remain on hold.

thanks
Shveta