Re: Skipping schema changes in publication
Masahiko Sawada <sawada.mshk@gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Cc: shveta malik <shveta.malik@gmail.com>,
Amit Kapila <amit.kapila16@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>, Peter Smith <smithpb2250@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>
Date: 2026-03-12T16:46:09Z
Lists: pgsql-hackers
On Thu, Mar 12, 2026 at 4:50 AM Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com> wrote: > > Dear Sawada-san, > > > I'm still unsure that the syntax like TABLE (t1, t2) for the exclusion > > list is syntactically correct. The syntax of TABLE (...) is already > > used in a quite different way as follows (borrowed an example from > > stats_import.sql): > > > > CREATE FUNCTION stats_import.pg_statistic_get_difference(a text, b text) > > RETURNS TABLE (relname text, stats stats_import.pg_statistic_flat_t) > > BEGIN ATOMIC > > WITH aset AS (SELECT * FROM stats_import.pg_statistic_flat(a)), > > bset AS (SELECT * FROM stats_import.pg_statistic_flat(b)) > > SELECT a AS relname, a_minus_b::stats_import.pg_statistic_flat_t > > FROM (TABLE aset EXCEPT TABLE bset) AS a_minus_b > > UNION ALL > > SELECT b AS relname, b_minus_a::stats_import.pg_statistic_flat_t > > FROM (TABLE bset EXCEPT TABLE aset) AS b_minus_a; > > END; > > > > Wouldn't it be more appropriate to use a plural form or the IN > > keyword, such as EXCEPT TABLES (t1, t2) or EXCEPT TABLES IN (t1, t2)? > > But there is an existing syntax to list target tables, FOR TABLE t1, t2, t3..., > which does not have the plural. Current rule is to use the singular for > specifying the exact table, and we follow. "TABLE t1, t2, t3" and "TABLE (t1, t2, t3)" are different to me since the latter reminds me of TABLE (...) syntax for defining a returning table. > > Or if we might want to add multiple items in the EXCEPT clause in the > > future we can have parentheses around all exclusion items as follow: > > > > 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; > > I agree those alternatives could work, but one downside is the redundant use of > "TABLE" when many tables are excluded. If we want to stay consistent with the > existing style, perhaps we could write it as: > > ``` > CREATE PUBLICATION pub FOR ALL TABLES EXCPET (TABLE t1, t2, t3); > ``` > > Because we have already been accepting the syntax like "FOR TABLE t1, t2, t3". > Yeah, we can omit the TABLE keyword for the second and subsequent tables. My whole point is that using different syntaxes for the inclusion list and the exclusion list would quite confuse users. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix miscellaneous issues in EXCEPT publication clause.
- 6b0550c45d13 19 (unreleased) landed
-
Change syntax of EXCEPT TABLE clause in publication commands.
- 5984ea868eee 19 (unreleased) landed
-
Add support for EXCEPT TABLE in ALTER PUBLICATION.
- 493f8c6439cf 19 (unreleased) landed
-
Allow table exclusions in publications via EXCEPT TABLE.
- fd366065e06a 19 (unreleased) landed
-
Add wait_for_subscription_sync for TAP tests.
- 0c20dd33db16 16.0 cited