Re: Skipping schema changes in publication - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: Skipping schema changes in publication
Date
Msg-id CAFiTN-vqyG_EJjuxi3PyqqATsWks3ZKJFy1CEKiF6T=08Mz0QA@mail.gmail.com
Whole thread
In response to Re: Skipping schema changes in publication  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Fri, Mar 6, 2026 at 4:26 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Fri, Mar 6, 2026 at 1:47 PM vignesh C <vignesh21@gmail.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
>
> 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.
>
> Option-2: ALTER PUBLICATION pub1 SET EXCEPT TABLE DEFAULT; Since the
> "default" state of an ALL TABLES publication is to have zero
> exceptions, the "default" will serve as an alias for an empty list.
>
> 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)"

I prefer Option-1  as it provides a consistent extension of the
existing CREATE PUBLICATION syntax. Since we already use FOR ALL
TABLES and FOR ALL TABLES EXCEPT... during CREATE PUBLICATION,
applying the same logic to ALTER PUBLICATION is intuitive and
maintains a uniform experience for the user.  So +1 for Option-1.


--
Regards,
Dilip Kumar
Google



pgsql-hackers by date:

Previous
From: Nazir Bilal Yavuz
Date:
Subject: Re: Don't synchronously wait for already-in-progress IO in read stream
Next
From: Marcos Pegoraro
Date:
Subject: Re: on SGML files is used for what ?