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 1wgeBF-006JL3-0w for pgsql-hackers@arkaria.postgresql.org; Mon, 06 Jul 2026 07:55:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wgeBE-00GAKf-0J for pgsql-hackers@arkaria.postgresql.org; Mon, 06 Jul 2026 07:55:52 +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 1wgeBD-00GAKX-2Y for pgsql-hackers@lists.postgresql.org; Mon, 06 Jul 2026 07:55:51 +0000 Received: from mail-qt1-x82e.google.com ([2607:f8b0:4864:20::82e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wgeBB-0000000216S-3L2t for pgsql-hackers@lists.postgresql.org; Mon, 06 Jul 2026 07:55:51 +0000 Received: by mail-qt1-x82e.google.com with SMTP id d75a77b69052e-51c21495722so14135391cf.3 for ; Mon, 06 Jul 2026 00:55:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1783324548; cv=none; d=google.com; s=arc-20260327; b=H42bBGeQm/n4raQhysI8SQ5c3rd31FuDNYybWLgypdTk3IOhhm62CQ0wcJEW7QwTpO BaOCD69hVfObHHl2Oo6FbgH4V2pYtSnGMMMsLs0aA1pCDTulU7Fplcx0eckZdgc43yJE 0fc4Peno7a9y3CC2Dr+62Kh8YDQc8A19/XlsCYuHk+whQxgjHiJOGvA2pSa+mVUpvGQb kWgfzK1aU/knaFMyvu8PuMPK+hlot7KrItera1zHa5xkIEvx8MXGm62iEpDvrnaIQuHX 607Tkg5So77CXDRfH7IGL8jxekGl7aZEfzwV4Ph946Sh/N1Zsl62qvs4tRn/KoBh8OMw s4bw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=U4p+tNtnb6hRkpAg9/+dfLhcKSm3LSlLw8lE5zweYZw=; fh=4jWYBGgfDd09AjBRRrTJZ4F4AzpnHngP/crbqwXbT5Q=; b=f0EwtMOm2iD1yNDrzsw7kDqwbDfnsHBoSpthrBGamgZROD1tb8gqTwSh9RiqHSWhbN 3g/4xh1hGt/+PvL1KWC+ouJJKV2rR9tJH44rrhztAlWqjM/dJpkQNg/ul3ndYlJVObRD wXVbdjEIJmJslK2bxY2U8qG/sTAuXiFq+KOs1ddcXCTnx3JtImNupVCsY4TKNntABCpT tYPRQhVJ2BQNFaY2kcduuhPXAL3qDjBcuCTLiJpAaFC0PjZs1vt9BqoeE/meKppZ4mNM rN6m8PRfjLGft2pdyjyXSeT+GmB6RvEL0GPfYsrIAz3YmgQA3itlbzl1KI2alfK92w27 PeYA==; 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=20251104; t=1783324548; x=1783929348; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=U4p+tNtnb6hRkpAg9/+dfLhcKSm3LSlLw8lE5zweYZw=; b=Q0m11X3gqmOkBXInjHpiHzS30c+AspIMfvlrNbO2ovMeAorVVOvkqmZBqyyeyvtr/C q0+aIUcFGmMbkiO9ESQq47Q6Q+H35aJ1+PA/Wm9b//ScZNcwtoTIxdGTjGsiUgCZ2gAO oFo4EMTpKWdcz7DGzxQfgjU+LqnEeRZbmskNl3OoBps8ssafmC/crWCe3PK/gTTDtcmI YrntlsfaYBNx27Qg0lFuzWdwkausuPgde9xpW6j/h+CqhwVNs6YnvdDIzLaMp2eTJOdd JFAUkYwMP3EpMoJd/99CHZCQGpBm7GTWGgm7qVUIk8EL5Fn5Xis63NheI3X7SWOiyd4+ zzVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783324548; x=1783929348; h=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=U4p+tNtnb6hRkpAg9/+dfLhcKSm3LSlLw8lE5zweYZw=; b=N16BIxI7Ky5Y0AKXgsq5GGoNf25nQYHnr+W53W670AbxAbF1kaoPTSiBiQ3cY6tmoe 1RtLQyO2dhQqiVjgD+1/vzicxTz/Frx2KzSEFmXpaKsFRJpZlxHSDT+nLobsAdj3AOKF w6dgb7WZjXtle2a/JkdK8t7ZhdtzZ4esP6fkcJtprxgTBjYcQKUqpZ1mWYKB7YgN9DE3 GZoZJ1P1zCA9BQrDmWujtJUln4789iadKFjPtvmlU9CZp5EHYcCaeQlKNPSe8vWH1JUs 4rSgX3Fv7WvZ5tjqpejwjjX6abJY6FjIeI/YW4G8Seh0xJXxVqkBKS6tnePx3kxuBFjV mguQ== X-Forwarded-Encrypted: i=1; AHgh+RocHyKmHFE9VLLMgskHnt84cq6+v+Es4cTolGvbTL5FRH6mOCV+r7RqN8ZZl+6ATebqJ0TFT88V2UnGTZZb@lists.postgresql.org X-Gm-Message-State: AOJu0YzkEMIy9Zo/1ds+kA/4xwJAg6F6e/PY3/t1UpjoG/fY/hoj9S1g wrLGn5Ncl7O1eE+mRGjSvh+IirvvuvFJEiYejSPl3REB5vqy+panfGy1OFED1x9jn6gzEqKDyj4 78ewBs55y84rNUmqlciP3rHT14zs7EPg= X-Gm-Gg: AfdE7cmDueVOcaTCd2Se5o97Khgpzxx09QrkCd+O8mqd5xpW+svAEw4hITWlp/fdhfO KY+RA2JDVgK6Iy3Qf5cPz0ffZpvsVmT5WUm/Iqii4t16akHs6cgvVkiVtdzUUnAf0Xxq5Vl03cy gYrzqFvVDIqeF586ASek2AAZk14tUImz1zoJ4qO7lRB5AsnzeggylCtOP2UStHhk57jG95JcCaA g4epeTGEd56aooe4Lj/cLETKTABfimB2SRRuotb1VZTq/X76tN78nQQnNvy7JjYiU6+47CAuxs3 b6MuF8tH0vT4+BbE0mAc/w6l6lc1OUNjAKJcqaPgzEYfcmOi1k3doQ== X-Received: by 2002:a05:622a:250a:b0:51c:1cbd:5fdc with SMTP id d75a77b69052e-51c4c1d8d58mr134140731cf.10.1783324548024; Mon, 06 Jul 2026 00:55:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Smith Date: Mon, 6 Jul 2026 17:55:19 +1000 X-Gm-Features: AVVi8Cdh2Bq8pnWBwAVX0NXi5tfZNrWrd6YsWHMKvfWbaMosvRWmudw3L4VIh6M Message-ID: Subject: Re: Support EXCEPT for TABLES IN SCHEMA publications To: Nisha Moond Cc: shveta malik , Amit Kapila , Zsolt Parragi , pgsql-hackers@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi Nisha. Some review comments for v18. ////////// Patch v18-0001 ////////// src/backend/catalog/pg_publication.c 1. + /* + * A partition cannot be independently included when any of its partition + * ancestors is in this publication's EXCEPT list. Doing so would leave + * the catalog inconsistent (root excluded, partition explicitly included) + * and the ancestor-cascade rule would silently override the include at + * replication time. Individual partitions cannot appear in EXCEPT + * (rejected above), so this check only applies to non-EXCEPT adds. + */ + if (!pri->except && targetrel->rd_rel->relispartition) It might be tidier to deal with partitions in one place. SUGGESTION if (targetrel->rd_rel->relispartition) { if (pri->except) { /* If in EXCEPT clause, must be root partitioned table */ ... } else { /* If not in EXCEPT clause, check ancestors are not excluded */ ... } } ~~~ 2. + errmsg("cannot add table \"%s\" to publication \"%s\"", + RelationGetQualifiedRelationName(targetrel), + get_publication_name(pubid, false)), + errdetail("Partition ancestor \"%s\" of table \"%s\" is currently listed in the EXCEPT clause of the publication.", "Partition ancestor .. of table" sounded odd. How about: errmsg: cannot add partition \"%s\" to ... errdetail: Ancestor \"%s\" of partition \"%s\" is currently ... ~~~ publication_add_relation: 3. + ereport(ERROR, + (errcode(ERRCODE_DUPLICATE_OBJECT), + errmsg("cannot add table \"%s\" to publication \"%s\"", + RelationGetQualifiedRelationName(targetrel), + pub->name), + errdetail("Table \"%s\" is currently listed in the EXCEPT clause of the publication.", The table was already named in the errmsg. It seemed redundant to name it again in the errdetail. SUGGESTION errdetail("The table is currently listed in the EXCEPT clause of the publication.") ====== src/backend/commands/publicationcmds.c 4. + ereport(ERROR, + errcode(ERRCODE_INVALID_PARAMETER_VALUE), + errmsg("table \"%s\" cannot appear in both the table list and the EXCEPT clause", + RelationGetQualifiedRelationName(pri->relation))); Do we need to name the clauses in this errmsg? Users can see what they typed. SUGGESTION errmsg("table \"%s\" cannot be both published and excluded") ////////// Patch v18-0003 ////////// src/backend/commands/publicationcmds.c PublicationDropTables: 1. + (errcode(ERRCODE_UNDEFINED_OBJECT), + errmsg("cannot drop table \"%s\" from publication \"%s\"", + RelationGetQualifiedRelationName(rel), + get_publication_name(pubid, false)), + errdetail("Table \"%s\" is currently listed in the EXCEPT clause of the publication.", + RelationGetQualifiedRelationName(rel)), + errhint("Change EXCEPT list using ALTER PUBLICATION ... SET TABLES IN SCHEMA ... EXCEPT."))); 1a. (Same as above review comment for patch 0001). The table was already named in the errmsg. It seemed redundant to name it again in the errdetail. SUGGESTION errdetail("The table is currently listed in the EXCEPT clause of the publication.") ~ 1b. Why hint to change the except list -- who says the EXCEPT list is wrong? It seemed more like a user error to me if they are trying to drop something from a publication when it is already excluded. Why does this need any hint at all? ====== src/test/regress/sql/publication.sql 2. I did not recognise the distinction in the test comments between "fail:" and "error:". ~~~ 3. +-- error: ALTER PUBLICATION ... DROP TABLE on an excluded table is rejected +-- with an EXCEPT-specific error; an EXCEPT entry is not a member. I don't think you need to say "an EXCEPT entry is not a member." -- what does that mean, other than to redundantly say an excluded table is a table that is excluded? ////////// Patch v18-0004 ////////// doc/src/sgml/ref/create_publication.sgml 1. For partitioned tables, only the root partitioned table may be specified in EXCEPT. Doing so excludes the root table and - all of its partitions from replication. The optional + all of its partitions from replication, even any partition that lives + in a schema which is itself included in the publication. BEFORE For partitioned tables, only the root partitioned table may be specified in EXCEPT. Doing so excludes the root table and all of its partitions from replication, even any partition that lives in a schema which is itself included in the publication. SUGGESTION #1 For partitioned tables, only the root partitioned table may be specified in EXCEPT. Excluding the root table automatically excludes all of its partitions from replication, including those in schemas that are otherwise included in the publication. SUGGESTION #2 (TI doubt you even needed to mention about other schemas) For partitioned tables, only the root partitioned table may be specified in EXCEPT. Excluding the root table automatically excludes all of its partitions from replication, including those that would otherwise be included in the publication. ====== Kind Regards, Peter Smith. Fujitsu Australia