public inbox for [email protected]
help / color / mirror / Atom feedFrom: Amit Kapila <[email protected]>
To: Dilip Kumar <[email protected]>
Cc: shveta malik <[email protected]>
Cc: vignesh C <[email protected]>
Cc: Peter Smith <[email protected]>
Cc: Masahiko Sawada <[email protected]>
Cc: Hayato Kuroda (Fujitsu) <[email protected]>
Cc: Shlok Kyal <[email protected]>
Cc: Nisha Moond <[email protected]>
Cc: Ashutosh Sharma <[email protected]>
Cc: David G. Johnston <[email protected]>
Cc: Zhijie Hou (Fujitsu) <[email protected]>
Cc: YeXiu <[email protected]>
Cc: Ian Lawrence Barwick <[email protected]>
Cc: Bharath Rupireddy <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Skipping schema changes in publication
Date: Thu, 26 Mar 2026 11:40:58 +0530
Message-ID: <CAA4eK1LBf5asit18HcqcFinOkdCjD6Lk2Eid9PDhtH6acwYb8w@mail.gmail.com> (raw)
In-Reply-To: <CAFiTN-s5PW121mBGKin20YEQpZkWefMehmP=v+0onzEaMQpwdw@mail.gmail.com>
References: <CAJpy0uB20MhJJEaPJdm31t4fykJ+fChA_76jU2P9HX5knbJvAA@mail.gmail.com>
<CAD21AoCC8XuwfX62qKBSfHUAoww_XB3_84HjswgL9jxQy696yw@mail.gmail.com>
<OS9PR01MB12149EA0C749BC29C7C949E32F544A@OS9PR01MB12149.jpnprd01.prod.outlook.com>
<CAD21AoBbZEshyaK0PeiF_J4_S75EfF=Gcs=C+X-osoVoUnawuQ@mail.gmail.com>
<CAHut+PssG+sHeV+Xo0g=S7xBb9FgDPjHYDR4iSuOdYXDq-Psng@mail.gmail.com>
<CAA4eK1LaSfAG7UAuy1xpnkWKM_YtrPuhbgAxYBFY3Sp_v_KqoQ@mail.gmail.com>
<CAD21AoAb8E8krN63cY_U7RQs9v-zkqUZyKT_UVKDwKfExtvTBg@mail.gmail.com>
<CAA4eK1K1GLR7DXSABayQE+pWM=v1ODD6haPYxuDhAYwJN5gjzg@mail.gmail.com>
<CALDaNm2kvFahDDvdgCNo=Nv-COz_N5Xw8YmzQBN2bd3g=N81fQ@mail.gmail.com>
<CAHut+PsCqTR_kQu5M1TqBjnE6KM5cO22aH8boHfpMa_gSJBmWg@mail.gmail.com>
<CALDaNm2OOgmNOPpABUU+AXzHhfrLG9HMfSd3jfNe=t3dc-kp1Q@mail.gmail.com>
<CAJpy0uCN4gfP7fSt__KdW5wYQ82650Z6L4YLnjRHZTQ1yir1mg@mail.gmail.com>
<CALDaNm32+c6RTE5xR6sJ=MZGgwEtzjkxpov_Hu70MXfbvmN+=Q@mail.gmail.com>
<CAHut+PtQbK9USLepyzArXFoNuLok1MsBu_Jg4UT=koZocombFw@mail.gmail.com>
<CALDaNm1tKuU479T=winBqoMb3MzO3Mta2juk8W3t2R5ps0_zyg@mail.gmail.com>
<CALDaNm3jpYs7ALcU6m5=Li=udidjZoW5dMpyCFs8QHGaf0S8+A@mail.gmail.com>
<CAJpy0uCWS=ybBKG-kRAfdWEe1VBNj+VqpAUUoT8MPaNS7EggiA@mail.gmail.com>
<CAA4eK1LMM-P4NatbkjG-96B7hHC7KYrJ8XTsCZQy0jLO9Qj4Bw@mail.gmail.com>
<CAJpy0uAyf71QSYitBf4WbCYq22HDR6LPdxB12TpTgTRpczwphw@mail.gmail.com>
<CAFiTN-s5PW121mBGKin20YEQpZkWefMehmP=v+0onzEaMQpwdw@mail.gmail.com>
On Tue, Mar 24, 2026 at 7:50 PM Dilip Kumar <[email protected]> wrote:
>
> On Mon, Mar 23, 2026 at 12:35 PM shveta malik <[email protected]> wrote:
> >
> > I would like to summarize the discussion/feedback for the EXCEPT
> > syntax implemented in [1].
> >
> > 1)
> > The currently implemented syntax is ([1]):
> >
> > CREATE PUBLICATION pub FOR ALL TABLES EXCEPT TABLE (a, b, c);
> >
> > There were concerns about why the TABLE keyword and the parentheses
> > '()' are required. These have been answered in [2].
> >
> > Please review the discussion there.
> >
> > 2)
> > Another feedback on current syntax was to move the TABLE keyword
> > inside the parentheses:
> >
> > CREATE PUBLICATION pub FOR ALL TABLES EXCEPT (TABLE t1, TABLE t2,
> > TABLES IN SCHEMA s1);
> > CREATE PUBLICATION pub FOR TABLES IN SCHEMA s1 EXCEPT (TABLE t1, TABLE
> > t2), TABLE t3;
> >
> > While this approach is workable, a downside is the repeated use of the
> > TABLE keyword inside the parentheses, which can become verbose. But it
> > can then be optimized to have:
> >
> > CREATE PUBLICATION pub FOR ALL TABLES EXCEPT (TABLE t1, t2, t3);
> >
> > This could be extended further in the future:
> >
> > CREATE PUBLICATION pub FOR ALL TABLES EXCEPT (TABLE t1, t2, TABLES IN
> > SCHEMA s1, s2);
> >
> > This approach gives users flexibility to mix styles, for example:
> >
> > EXCEPT (TABLE t1, TABLE t2, TABLE t3)
> > EXCEPT (TABLE t1, t2, t3)
> > EXCEPT (TABLE t1, t2, TABLE t3)
> > EXCEPT (TABLE t1, TABLES IN SCHEMA s1, s2, TABLE t2, t3)
> >
> > While flexible, this can reduce clarity due to mixed styles, making
> > the statement harder to read. If extended further, the syntax could
> > evolve into something like:
> >
> > CREATE PUBLICATION pub1 FOR
> > ALL TABLES
> > EXCEPT (TABLE t1, t2, TABLES IN SCHEMA s1, s2),
> > ALL SEQUENCES
> > EXCEPT (SEQUENCE s1);
> >
> > At this point, one might also question why not allow something like:
> > FOR ALL (TABLES, SEQUENCES).
> >
> > Additionally, this shows a potential drift toward less structured
> > syntax. Instead, with the syntax already implemented in [1], its
> > future extension would look like:
> >
> > CREATE PUBLICATION pub1 FOR
> > ALL TABLES
> > EXCEPT TABLE (t1, t2),
> > EXCEPT TABLES IN SCHEMA (s1, s2),
> > ALL SEQUENCES
> > EXCEPT SEQUENCE (seq1, seq2);
> >
> > Although slightly more verbose, this approach keeps each clause
> > self-contained and explicit. The meaning of each part is determined
> > locally, rather than depending on elements appearing far in the
> > statement.
> >
> > The current syntax in [1] is simple and easy to follow. We have
> > retained the current implementation for now, while remaining open to
> > further discussion and suggestions.
> >
> > [1]:
> > https://www.postgresql.org/message-id/CALDaNm2-Ob9qPR%2BvqUSVMkxYO8RW4LQ_S1XiB0Y7xa54U%3DDqbA%40mail...
> > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=fd366065e06ae953c4f2d973d5c5f0474...
> >
> > [2]: https://www.postgresql.org/message-id/CAJpy0uB20MhJJEaPJdm31t4fykJ%2BfChA_76jU2P9HX5knbJvAA%40mail.g...
>
>
> Thanks for the summary. While I find the current implementation
> simpler and more intuitive, and would prefer it if we were designing
> this from scratch, we must consider the existing patterns for table
> inclusion. Since the inclusion syntax already supports a mixed
> approach, users will likely expect the same flexibility for
> exclusions. For the sake of consistency across the features, I believe
> we should move toward the mixed approach, despite my preference for
> the current structured style.
>
IIUC, you think that we should change the current syntax "CREATE
PUBLICATION pub FOR ALL TABLES EXCEPT TABLE (a, b, c);" to "CREATE
PUBLICATION pub FOR ALL TABLES EXCEPT (TABLE a, b, c);".
By now multiple people (Dilip Kumar, Peter Smith, Sawada Masahiko)
have preferred the alternate syntax, to move TABLE inside () to make
specifying inclusion and exclusion list in a similar way. Unless we
have more feedback, I think we can change it now.
--
With Regards,
Amit Kapila.
view thread (377+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Skipping schema changes in publication
In-Reply-To: <CAA4eK1LBf5asit18HcqcFinOkdCjD6Lk2Eid9PDhtH6acwYb8w@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox