Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w0Nkz-001rK4-0c for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Mar 2026 17:54:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w0Nkx-00AmpU-1y for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Mar 2026 17:54:04 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w0Nkx-00AmpM-0s for pgsql-hackers@lists.postgresql.org; Wed, 11 Mar 2026 17:54:03 +0000 Received: from mail-lf1-x12d.google.com ([2a00:1450:4864:20::12d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w0Nkv-00000002AoY-0w74 for pgsql-hackers@lists.postgresql.org; Wed, 11 Mar 2026 17:54:03 +0000 Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-59de8155501so225811e87.3 for ; Wed, 11 Mar 2026 10:54:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773251640; cv=none; d=google.com; s=arc-20240605; b=Hlof+4xWtiChVew97QcBWByIMPEgDpYL61wFnaxFRWg4ek6v6AYubQviJ0RiKjvt4N nTWcXwP8GFdJAFuAJekMSTnocnN+0dZDqJgNQ6sQqN3NpFg/WN7ixC/ga096Z9YLhBlj wjh9+uh3G73Z7kJfU0t9kcaxUoYgO7mwNgsPA0ILUJwheiyw3syM8x2oYepWHD7uV3ZZ RpASC6JuQB1fJTsrsl5eaU/fXL8G9YrZFDmYiD3Aobsa8lX9kv738bIGhHAWwsxjAsEc 52BS/ol2VR+Z4R/Y6RDUscgsuus11IbFPK/CH55rFbIGf5D5RTsx+F7o2O5qfrTrOOMr 7M/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Wd1bUG1PQmSmrcxgUdvfHwB6hKX4OH5EuOMikAUIp0w=; fh=12oviitnu1VoPS3WnVR9KdwX1mIASQoj6nV+bZde/LE=; b=GAdpOX24beW7uILWNqJYfG/fgCkeo/ZkHBJAB2lSo1zhjPIATBSMJEyCLOVO83AVgb 1D2iSSQ5rxVvG+k40xRxQqC17rvNhpvdd9xHTvy6vECCGnZFWxpv6ejosgSYBpJsNfgA /2JyOZU2pUUoEvcVEa4UfezRWsKHPTqqeWWI5AacxSE++fVVflp3x4VwX0mTtPffPD4l LZGHzGOKQE3XGQNtqiJguUwxSDXIP6IweM0+ItZ1u3K2y6BVTxJSjSG0iGYgA7WRcNfn KYLjf9Ih7CcFFWE3k40JwlZLRi3yFUEUmbn7CB3CgUduw6B4zNWxzdBdVJ9LV1UqKsWP Gncg==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773251640; x=1773856440; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Wd1bUG1PQmSmrcxgUdvfHwB6hKX4OH5EuOMikAUIp0w=; b=KHLx4McwHXRm7EGdgjXfbVEMSHaMUtZrlmyWF4bbrl0sEbPP9iBX7Si41zHXrZqhU+ ynj2y3kmEKLj9lsICJREkd0+HWbFLZDopBmCxRFmOadYU4Ui2WWja3Sd8m5U5HM6UMm4 ZXSHueR9lcg4BKA2peYVugDaxPTqF98rtCDOOcTUHPAMcj62dWNJre7Bi5MYfC/gpX0I pPcmNa/P1346OqzDKh6pqa7JQKtjhbGNMM74dWYiwLPeFarR+E1uiyQOokM548/ATijE Bz/rv27Utd9H/2P+hRm4r66prFjvY/ZN+Z1WC53/+28ANncfHgwtVWVJsh/PNnvwr/SI FrhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773251640; x=1773856440; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Wd1bUG1PQmSmrcxgUdvfHwB6hKX4OH5EuOMikAUIp0w=; b=U5Ebi/Ef91rMIYFvJuSh6dJKVNur4++2rLt6xrvRvuxwwPFRJOBKMPyAwxJt6AX2Z0 Oho2oH4q1zvfr7nA+EgpNeLlP1XQSDhIiANkiwiA+JZJtfhCaXmNFs72p7/Sa0p336zu V7SAOl68za6ZlpkOo68JZijVA/GZ6H/Dyzo1ZCTCj4O+MlQEOUllCrCuC9IkmuSNiflW 187WvDhuZYDT2isocwP4Nw8X7Ql3c2V3CQj5sIZX7AvlbC/KDPHsYNhQXb+Ci/f12BR9 hY/vfKKIh+ZzdpHuYPaQWIFtbJoruoSbPjf3ZhqUqCweFmdf2RVs95uacrPyYy3PlkBw LU4w== X-Forwarded-Encrypted: i=1; AJvYcCWbYyA3uIzrMhO3JfmJCFxln5Y1KzDJ7RU4oVYl2ov82NRlGU7ZSTqiDmQo06rutUSlm1U7hxvW0iN6XTgN@lists.postgresql.org X-Gm-Message-State: AOJu0Yw8SE7SRWDGUbTzpBvNLKqMs8Yqy4y++wMFs1CIAe91Rx5RHxSC vZoYx5IjAoI0NOw1/xinGN+z4EFYWWI0PT/fhP4YaW4QHPiILUT5r/hzdmPDVEZf0DNNbSOpQlf utKareHkpoXbJwMRncHBT/PTSE7yyMtI= X-Gm-Gg: ATEYQzxaAcJj0nM9Cc0fiIWu1K1p5eKurv5rcIcTaCwNGj8OZZfoX8PB10r7mGC2ktl EbE5BwMMp6KvyR/Nds2gBSpivDU41UUKfJO+HcLro4yc4Wjl4a3EHDY2+GM1paInOjBwgPaJA5n i+a4Jw1cUs7GZlb5783jR2Ht49waFZgUKFGcbTQZSH49TteVTvtSnacg3L2Z+ANeL0xiEvcpRvB 6MRb5L+YHBjb6oQBqLFKONlW/pM4Cf4we22IXZfWs6FKGSOFHYyzNT+ELzjspgIa6Jncaj3jjs5 dUqmGgLp X-Received: by 2002:a05:6512:1292:b0:5a1:44c9:a8ef with SMTP id 2adb3069b0e04-5a156cd15c0mr1232020e87.26.1773251639763; Wed, 11 Mar 2026 10:53:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Masahiko Sawada Date: Wed, 11 Mar 2026 10:53:22 -0700 X-Gm-Features: AaiRm52Wddfjq6-EidEoUkKAk1ZiiOshikU66InqeT4oURQyNlIECWyaBFX5sIc Message-ID: Subject: Re: Skipping schema changes in publication To: shveta malik Cc: Amit Kapila , vignesh C , Shlok Kyal , Nisha Moond , Ashutosh Sharma , "David G. Johnston" , Dilip Kumar , Peter Smith , "Zhijie Hou (Fujitsu)" , YeXiu <1518981153@qq.com>, Ian Lawrence Barwick , Bharath Rupireddy , PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Mar 10, 2026 at 8:24=E2=80=AFPM shveta malik wrote: > > On Wed, Mar 11, 2026 at 2:25=E2=80=AFAM Masahiko Sawada wrote: > > > > On Wed, Mar 4, 2026 at 3:01=E2=80=AFAM Amit Kapila wrote: > > > > > > On Wed, Mar 4, 2026 at 2:49=E2=80=AFPM shveta malik wrote: > > > > > > > > On Wed, Mar 4, 2026 at 1:54=E2=80=AFPM vignesh C wrote: > > > > > > > > > > Here is an updated version with a couple of typos fixed and separ= ated > > > > > the describe table query based on versions which make it more eas= ier > > > > > to read. > > > > > > > > > > > > > v56 LGTM. > > > > > > > > > > Pushed. > > > > Sorry for joining the discussion late. > > > > I've tried with the new EXCEPT clause and I have some questions about > > the newly introduced syntax. With this feature, we can now write: > > > > CREATE PUBLICATION pub FOR ALL TABLES EXCEPT TABLE (a, b, c); > > > > The exclusion table list is written in the form of TABLE (a, b, c) but > > it's quite different from the inclusion table list we can specify > > (e.g., TABLE a, TABLE b, TABLE c). I'm concerned that it could confuse > > users. Have these points already been discussed? Also, isn't the TABLE > > after EXCEPT redundant? > > > > Thanks for the question. > > Yes, these concerns were discussed earlier when the EXCEPT syntax was > introduced. The current syntax: > > CREATE PUBLICATION pub FOR ALL TABLES EXCEPT TABLE (a, b, c); > > was chosen intentionally, mainly for extensibility and to avoid > ambiguity in future enhancements. > > 1. TABLE keyword after EXCEPT > > At first glance, the TABLE keyword might appear redundant. However, it > becomes important if we later extend the syntax to allow excluding > other object types, such as schemas or sequences. For example: > > CREATE PUBLICATION pub FOR ALL TABLES > EXCEPT SCHEMA (s1, s2), EXCEPT TABLE (t1, t2); > > or potentially more complex combinations such as: > > CREATE PUBLICATION pub > FOR TABLES, SEQUENCES IN SCHEMA sch1 > EXCEPT TABLE (t1), EXCEPT SEQUENCE (s1); > > In such cases, explicitly specifying TABLE (or SCHEMA, SEQUENCE, etc.) > after EXCEPT avoids ambiguity and keeps the syntax consistent. I understand that it's for future extension but I'm still unsure that users would not be confused by the fact that the syntaxes of inclusion list and exclusion list are different; TABLES IN SCHEMA s1 vs. SCHEMA (s1). > > 2. Parentheses around the exclusion list > > Parentheses are required to clearly separate the excluded objects from > other elements in the publication definition, especially when mixed > with inclusion clauses. For example, consider a future case like: > > CREATE PUBLICATION pub > FOR TABLES IN SCHEMA s1 > EXCEPT TABLE (t1, t2), TABLE t3; > > Here it is clear that t1 and t2 are excluded, while t3 is explicitly > included. Without parentheses, a statement like: > > CREATE PUBLICATION pub > FOR TABLES IN SCHEMA s1 > EXCEPT TABLE t1, t2, TABLE t3; > > would be harder to interpret and potentially ambiguous. > > So although the syntax differs slightly from the existing inclusion > list (e.g., TABLE a, b), requiring both the TABLE keyword and > parentheses after EXCEPT helps keep the grammar unambiguous and makes > the syntax easier to extend in the future. 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)? 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; > Original discussion is at [1]. Thanks. I'll read the discussion. Regards, --=20 Masahiko Sawada Amazon Web Services: https://aws.amazon.com