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 1wfDL3-005Kpx-21 for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Jul 2026 09:04: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 1wfDL2-00161z-1T for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Jul 2026 09:04: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 1wfDL2-00161q-0E for pgsql-hackers@lists.postgresql.org; Thu, 02 Jul 2026 09:04:04 +0000 Received: from mail-pl1-x635.google.com ([2607:f8b0:4864:20::635]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wfDKz-00000001LrK-2kX8 for pgsql-hackers@lists.postgresql.org; Thu, 02 Jul 2026 09:04:03 +0000 Received: by mail-pl1-x635.google.com with SMTP id d9443c01a7336-2c9b42be8feso16253505ad.2 for ; Thu, 02 Jul 2026 02:04:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782983039; cv=none; d=google.com; s=arc-20260327; b=TWWMaVKbX9WdFAIU/hWVoFLvbkMjUy44raHpCq8rK6rBAdPCGWAm4exSKWhxPpF0Aw svCASYEVd7o0PtEkI/nt+GW6VM1aVuXBbr8SG/Qcb6ovfWCJ4+GkVdu1kzHxs8MvEwL3 fnwoP7EFMNP2DVXqB9SqzcTv+DxmTy8oHN0jAAc8pzcyqaTd4570YmuzpvDtOzDp20gX wTi4Qqa5EPjYB3u5v5cEeH9gwA0dU/ac2sfJ642O2OtdJZegJzf+lUHN6E75A7s8j+vI g0pavaQ7RSGAmtMEITElsmeMYh8vZgUicVr7a39bEHs4E34c3C1PK6iQBwb9ND39yoWv bMlw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=t1GSm6QFeys1F6fujH5ZI1pJkrhkKxi9yD9ioBR/hZE=; fh=/4s9DCGRkeEnc13Ol7kiuuqueAl+wIlF8YZezVSoDkg=; b=IUkLi67bud0aEBa2FsPJSUwFtVCyHHzD305+Wcb0cv9p+Ofco3gfmyaXreOVTZXyVp /TJ3XIo4BTVIDxU7YGr2SRGt0ifuT5L0J88t8gFH7a+5Dc9Qoa7fE+h54JIdm3PXSSoL cjCk7bAUMl/3rdkZJ8byLJvOsp5e1GbBdzz/mdYG4h7vs1zUTX7iBm66VwmXUurMO3fL 3r5UrUe0RaCWY7YSl7f5TAE3U4JGyoqZS6YgWl+lnBd8oK0uaO9FJU6yPceTyIddwNgL VyIKy6jL2EKczij3aCh/20hYz+XBnPMR3/ObRmyzz4F41oQwnrKToMXYuJN7V0ZjLBlF duPw==; 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=1782983039; x=1783587839; 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=t1GSm6QFeys1F6fujH5ZI1pJkrhkKxi9yD9ioBR/hZE=; b=JsJfrMrZAzZg13nNHypGDIEwlsd/O+yStA9AcRw18m3Mwc/qOyoXIdLC8mDVVw15rh tDRiDmvqJsQpFgzU1OJ6sxXSPrfprAqzqCTSAesbfeyWEfpeXrN2G5Y34OqcGv8PV16i WOZPzBNz2YbM9VDKc776Ci2yvbTMtrprFPTUNJW8mCcuLXVLJTxTM33/R5DtYhvC75K8 HNElfslJeArnjNkmXO8qol8IGFN2zrL/9SbFHg3ucV1ZcmiBsR7CyTfTbFB+Tbp1J+cr NSnWpSPcRtIJrTO83kWT0LdDyoZkix0OJSA6yiewhx/giiZaNwq+mA+I2KqjWn9qEDfr W2Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782983039; x=1783587839; 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=t1GSm6QFeys1F6fujH5ZI1pJkrhkKxi9yD9ioBR/hZE=; b=b+HybDaw0JcndR47DedIE6Y+0ict5MjfubYudWdZjXJtpXUyc5yvUbV+dLmyUzPJvu 43nBjMjDEb+CNEI5Z7E/nvA+aRCo0a+rGr7sYwY1laaniPU3xqhAIcXjaUnPLaq7u4ZB 2LnxWxKiOXuRBUlBklDucD3fQXYpa/S+cKHNeX3q3pKN519cBE4rdW5PEFQI8aKpdVWb iqKYsasmpsxvFckiH4TV/mOhVLJdN/xr4o0yoWFWB8k4VkUCcGggxarS/jOvwsy5sSFH M8GG+K65hrKHLh8nMMCRG94WjNp9/h9IpWPKqkbGuiqTdlhJ4Ah+SBkEno5i6t1Ca+oO stVg== X-Forwarded-Encrypted: i=1; AHgh+Ro6T3YY7M0QImBBZhJGUu3Y5nJMsFJE5hnJKwJjo893zdqWLSn8gpDOxnzH0gzF95lpq5f9GObaHbvLb6Wk@lists.postgresql.org X-Gm-Message-State: AOJu0YxqCQT+TrK7ohe5uf/o5rhuZU77tT6SvIE78eg1COYIEPmtzLUd 4FqnS3qD1ijubEdKz4EYSwoxm9F3HuulicuaoPw8ESUjYpiMeiErHFkp/UPt0Vr9JJ76SgkZDSm /+Ze9pvMgGzYhckjPj7iMYuPp0bei/00= X-Gm-Gg: AfdE7cnTDg330yYGr9T9GOpIs7VkKzyVpIZO/ytlGTadBVO2cICVz5MdT6t3AT6+fTr rpn9C7iY6CFsQWzaTuou4mm0jRApfQNkQZbAbwJ6TNigJxDW817+Lq55dZgXv8Q7BUQ2MTmKuxL ZmClvfTBc1ejVHdSadfEiYlKuHy+jfJ2rFPIS7Z+ej2VjiioLZR9CJ0VkaDaFhKM3wKtbo+ja2W xYz6WtPJQFPGED4pV9Ldd0KETXcyCcD72CHIe+fCw3eOdaUI/D5CbdW670k0cN7C0/MeOb6bOUh yZDoFKAA2q9XT6pVSTiDb7Tb7RW0OJj3ccoGSCoOfGPXtYi9zLjY2fdLISUT9mB/jIslcNp4Pxt GW1gpBHDLOOvkQD4LJ4jCuIHy/zOXdA== X-Received: by 2002:a17:903:1252:b0:2ca:bb7e:29a7 with SMTP id d9443c01a7336-2cabb7e2de6mr800325ad.41.1782983039300; Thu, 02 Jul 2026 02:03:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Amit Kapila Date: Thu, 2 Jul 2026 14:33:47 +0530 X-Gm-Features: AVVi8CcmHIQEk1miwGzMVZysy-uMyCxbXhVdnYrBILb-gjifurJv6TT7qarDsNY Message-ID: Subject: Re: Support EXCEPT for TABLES IN SCHEMA publications To: shveta malik Cc: Nisha Moond , Peter Smith , Zsolt Parragi , pgsql-hackers@lists.postgresql.org 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 Wed, Jul 1, 2026 at 3:54=E2=80=AFPM shveta malik wrote: > > On Wed, Jul 1, 2026 at 3:42=E2=80=AFPM Nisha Moond wrote: > > > > During tests, I found one behavior that needs discussion: > > > > Consider a partition hierarchy where the root table is in schema s2, a > > child partition is in schema s1, and the publication includes both > > schemas but excludes only the root table. > > This is the exact scenario I had in mind when reviewing > 'get_rel_sync_entry-->GetTopMostAncestorInPublication' flow, thus I > suggested adding comments about intentionally fetching the 'Exclude > list' only for the Root. I was about to test it in my next review > cycle. > > The first thought is that if root is excluded, the partition should > also be excluded to maintain consistency with the 'ALL TABLES Except > ROOT' behaviour. But then it needs to be documented too. > +1. It is good to be consistent here with similar ALL TABLES case. BTW, as we can't exclude the child table explicitly, this anyway seems like the only option because otherwise, users won't have any way to exclude the child table. --=20 With Regards, Amit Kapila.