MIME-Version: 1.0
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>
In-Reply-To: 
 <CAD21AoAb8E8krN63cY_U7RQs9v-zkqUZyKT_UVKDwKfExtvTBg@mail.gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Sat, 14 Mar 2026 15:05:21 +0530
Message-ID: 
 <CAA4eK1K1GLR7DXSABayQE+pWM=v1ODD6haPYxuDhAYwJN5gjzg@mail.gmail.com>
Subject: Re: Skipping schema changes in publication
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Peter Smith <smithpb2250@gmail.com>,
	"Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
 shveta malik <shveta.malik@gmail.com>,
	vignesh C <vignesh21@gmail.com>, Shlok Kyal <shlok.kyal.oss@gmail.com>,
	Nisha Moond <nisha.moond412@gmail.com>,
 Ashutosh Sharma <ashu.coek88@gmail.com>,
	"David G. Johnston" <david.g.johnston@gmail.com>,
 Dilip Kumar <dilipbalaut@gmail.com>,
	"Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, YeXiu <1518981153@qq.com>,
	Ian Lawrence Barwick <barwick@gmail.com>,
	Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAA4eK1K1GLR7DXSABayQE%2BpWM%3Dv1ODD6haPYxuDhAYwJN5gjzg%40mail.gmail.com>
Precedence: bulk

On Fri, Mar 13, 2026 at 11:51=E2=80=AFPM Masahiko Sawada <sawada.mshk@gmail=
.com> wrote:
>
> On Fri, Mar 13, 2026 at 2:51=E2=80=AFAM Amit Kapila <amit.kapila16@gmail.=
com> wrote:
> >
> > On Fri, Mar 13, 2026 at 8:55=E2=80=AFAM Peter Smith <smithpb2250@gmail.=
com> wrote:
> > >
> > > Hou-San (off-list) gave an interesting example of how it might look
> > > when the example is combined with the hypothetical future ability to
> > > exclude all schema tables from a "FOR ALL TABLES"
> > > CREATE PUBLICATION pub FOR ALL TABLES EXCEPT (TABLE t1, t2, TABLES IN
> > > SCHEMA s1);
> > >
> >
> > So, if we follow this, in future, the syntax would look like:
> > Create publication pub1 FOR ALL TABLES EXCEPT (TABLE t1, t2, TABLES IN
> > SCHEMA s1, s2), ALL SEQUENCES EXCEPT (SEQUENCE s1);
> >
> > I think if we use the above syntax then one can also argue that why
> > not use FOR ALL (TABLES, SEQUENCES) instead of ALL TABLES, ALL
> > SEQUENCES.
>
> The same is true for the syntaxes of TABLE(t1, t2) and SCHEMA(s1, s2),
> no? If we allow grouping the tables and the schemas by TABLE and
> SCHEMA keywords respectively in exclusion lists, one could argue why
> we don't allow it for the inclusion list.
>
> >
> > Instead the current command would like:
> > Create publication pub1 FOR ALL TABLES EXCEPT TABLE (t1, t2), EXCEPT
> > TABLES IN SCHEMA (s1, s2), ALL SEQUENCES EXCEPT SEQUENCE (seq1, seq2);
> >
> > Though it is slightly lengthy it makes the syntax local such that the
> > meaning of a clause is determined by what is inside it, not by
> > something that appears ten words later.
>
> While it helps the syntax locality, I'm concerned that it could make
> the context of the EXCEPT clause ambiguous. For example, IIUC the
> above syntax rule would allow us to write:
>
> CREATE PUBLICATION pub1 FOR ALL TABLES EXCEPT TABLES IN SCHEMA (s1),
> EXCEPT TABLE (t1);
>
> Regarding the second EXCEPT clause, while one might think it excludes
> t1 from ALL TABLES, one might think it excludes t1 from the first
> EXCLUDE clause (i.e., the publication actually includes t1 in the
> publication).
>

According to me, the comma between EXCEPT clauses breaks such a chain
of thought but others may think differently. The docs can clarify such
a confusion if any but if multiple people interpret it the way you
think, I am fine to go with the direction you are proposing. I am
slightly worried that both syntaxes have some pros and cons, so even
if we change to what you are suggesting, one can argue to go back to
previous syntax as that also has some merits. So, I feel we can
complete the pending patch [1] and try to get the opinion of some
other people unless changing the code to support another alternative
is difficult.

[1] - https://www.postgresql.org/message-id/CALDaNm1SGJtJq_W68khExG1EL4ZmyZ=
2U7JSc1Z3FsYr4nSbi_A%40mail.gmail.com

--=20
With Regards,
Amit Kapila.