Re: Skipping schema changes in publication

From: Andrei Lepikhov <lepihov(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>
Cc: shveta malik <shveta(dot)malik(at)gmail(dot)com>, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>, Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, YeXiu <1518981153(at)qq(dot)com>, Ian Lawrence Barwick <barwick(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Skipping schema changes in publication
Date: 2026-03-06 12:55:23
Message-ID: 109c66bc-2871-4fba-8dc1-c57d183e9515@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 6/3/26 11:56, Amit Kapila wrote:
> On Fri, Mar 6, 2026 at 1:47 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>>
>
> Instead of a syntax like "ALTER PUBLICATION pub1 DROP EXCEPT TABLE t1"
> to allow resetting the entire except list by incrementally dropping
> the except tables, I could think of following alternatives

IMO, using the 'DROP' syntax is an unusual choice because it does not
match how an alter publication process actually happens.

>
> Option-1: ALTER PUBLICATION pub1 SET ALL TABLES; This suggests it is
> still an ALL TABLES publication, but providing a new definition. Since
> it didn't include an EXCEPT clause this time, the exception list is
> now empty.

I vote for a style that allows incremental add/remove table.

> If we follow the first one, then we can choose "ALTER PUBLICATION pub1
> SET ALL TABLES EXCEPT TABLE (t1)" to set a new except list instead of
> "ALTER PUBLICATION pub1 SET EXCEPT TABLE (t1)"
This approach works best for me. It also matches the internal
replication logic: take the new publication state, compare it with the
old one, and process the differences.

--
regards, Andrei Lepikhov,
pgEdge

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sami Imseih 2026-03-06 13:11:27 Re: [BUG + PATCH] DSA pagemap out-of-bounds in make_new_segment odd-sized path
Previous Message Andrew Dunstan 2026-03-06 12:33:31 Re: Emitting JSON to file using COPY TO