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 1vmnAt-00GIFJ-0x for pgsql-hackers@arkaria.postgresql.org; Mon, 02 Feb 2026 06:12:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vmnAq-00Bozy-08 for pgsql-hackers@arkaria.postgresql.org; Mon, 02 Feb 2026 06:12:36 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vmnAp-00Bozp-20 for pgsql-hackers@lists.postgresql.org; Mon, 02 Feb 2026 06:12:36 +0000 Received: from mail-pj1-x102d.google.com ([2607:f8b0:4864:20::102d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vmnAo-000000008tq-1Hvz for pgsql-hackers@lists.postgresql.org; Mon, 02 Feb 2026 06:12:35 +0000 Received: by mail-pj1-x102d.google.com with SMTP id 98e67ed59e1d1-3543b9f60e3so1397998a91.3 for ; Sun, 01 Feb 2026 22:12:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770012753; cv=none; d=google.com; s=arc-20240605; b=axRDISLsiXN+CJdEoGaVzXl9WFC6MlrE5ZtVVGdMxvgdKmj2wRa+d0/NruSX7figtN zkm9X1ckO0kxmAiCNKBx21mNwB8wL71xChl1FNCNigxPvAPY7uBK7g5LkI6qmg6v/gXF rKHvZ5FyhLaoaMErlqVnWYo/UiDUptagWpBe06sMbLicUYJd2Tl5d5GB3AGzlyaM/qi1 HnAYAbHhVZjePw9rRK8iq2K1Q0Br5/SbaZDG/Hl/GECzRV7PadiIp5VF4zvwV/04YI/n K53y0dnXnia7goTr22EO+NeRLpwr6gbxur7vyA14zf0gFJTzdB4qi5mJoCbT0Pzcyb+h nXxQ== 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=xL3gugOX+bvqzbfqGEVpVWQ+L9jdZcpAq8RyomQPBhU=; fh=9Sr7sLX1ntloJAVPB9EYn6bZaZOqErqHyG5qfP66hx4=; b=ZFyhwFy9qoeP2bolabj3elPs5TGkvaJY0YkbIGVpCHxCARSsIuCTghS5h5NduvIWip cBuWXfVN+mxr0ZBRrQR2HbllAkgJX3erkmM1NqnWN/Hw/K7YG3KYEXa/5RpicuGxWXAV BCFkWvaoH/rOr5xxqr/35OfqpxVJxMU+LkR/hABS/vbX4kC6GCcMf8SYdyG+CgY8qmJu dVtciA1mK7iymxbjufxA8471xHS0cxguzhQWW1btPcyFLFYuZX3F4p8mzbke3rz8TA3Z LaNHvr5BptNricFNgF21hYzue8YA6B/RF30C+lTYIhqquAPuQ35Ets1Rs0wZf2bwJFaR To1Q==; 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=1770012753; x=1770617553; 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=xL3gugOX+bvqzbfqGEVpVWQ+L9jdZcpAq8RyomQPBhU=; b=KTEydYnxyCMqhkd55gdSWnEkJ55MvXx7bDWJTFP6fi2aLggonAj1jDN+CwXuuppz6e re7wQPbRbZux8qjtdk+7Iqq0sRqN9Ba1rzl7lNjWqgeEY+K+MK3oVENtS7F19ObOzvJe VtkyTbT7Ok2b9tv2XlksJXro/OpZiuE4JZdMacI3w+7imbeAa/HmfUAJy1sFXZC2Uu1I vQEwWC1+iY0QawfwyI2s8TsLYwXchrkDcrKnoze+FFwSsji3rdLD8Zru7tL59Ph3dMxz gcfBWcWZSR79g+yBJ7l6yvT1O0ZDyS8y6yxSo/ZOOP7hcnYbBjzwIfOyQU079OEYpOnr 0rgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770012753; x=1770617553; 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=xL3gugOX+bvqzbfqGEVpVWQ+L9jdZcpAq8RyomQPBhU=; b=q/a6FOHHyY9Mu7eTu4YwtoCN4DaImZK95Ai+tQeIYyi5Of3N6A6c3zxBfKEWO6kbpP LFaN24ncl9RdOU6DklepQloNYqt6QRIcmsKmFKEtu9PGaGwdZUvEIM174jikDPAAHbM5 pBzzTk0JQlglG306oj9GTieO+BBPgpAnokK8uHktCVPLlRAh+hsbcIYNWho881TEa9V5 mvqCeLUwrCwq400QR8WNk7/ftpp89Ni+t2rwPr9hQFMAnsRlllbNiqXL6JositkIJKd9 etJ4sBFnkoIBp5Io9FV2CqkGeal7N7A8LMVaZM1s9mkUifBNQ7dAFm/SsnZtF+JsM9+n mYBg== X-Forwarded-Encrypted: i=1; AJvYcCXAlsaCh3UhoaX4qtCEJDqHvyCYZQ1tBshyUU2om67nw6RhVbesHgC3as2NBUDrKaHmLZy6Q3P1Yrfu/GWp@lists.postgresql.org X-Gm-Message-State: AOJu0Yw8XovzbN9CJ0Ezof8pBK/zHFlpFYyFfQtQcqDc6fU61m+UrGJD g26GDo76Jtelc14TLdoDHqpp1R/jPsnzNgk16fywghcKSIog/kSLf4HynLndQ7ql5GAjWU1y594 7/0wot2lK5S4IH3Zbk9O9pXnLQ+oBy6I= X-Gm-Gg: AZuq6aKuRJ799ue9FOtZX6ePHtQb2Y5ruyE1qcPOhmuXNfMS0u/e2no7PrO19S9EVQT Kdwa/f8iGffsLHe1VaC36BUjAPyhvsh+VAQ8hnj64G1hR/9wSxjIz8fqHVJNJ2ENamfG6stlQpP eyNOryWMytObgNBp3o6JJkQAqR5gZeauOHj0dzJ+opG/4EBzH4NEfWcpLsB0LTB9+9FknzwAQiY 0oEnqEAQkLsOaNbfCeNZKV9vxA/TeC1GZkYy2Gzwh7IgeZasrY8SGwTMnZiAF/ag5hvzge+qx7e KkR/XIcx80PAZ6lfrvM/AEhBNOYfJkIXVrpg1Bt5JFdYpgAIiW8= X-Received: by 2002:a17:90a:d604:b0:343:edb0:1012 with SMTP id 98e67ed59e1d1-3543b3ae4c4mr9673673a91.21.1770012752777; Sun, 01 Feb 2026 22:12:32 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Mon, 2 Feb 2026 11:42:21 +0530 X-Gm-Features: AZwV_Qj1zshX3neX-9NmgTSCnQhBk_O0g1DlY84qmnoCvrU9lRk5aAAqMC5NFVA Message-ID: Subject: Re: Skipping schema changes in publication To: Peter Smith Cc: vignesh C , Dilip Kumar , Amit Kapila , Shlok Kyal , "Zhijie Hou (Fujitsu)" , YeXiu <1518981153@qq.com>, Ian Lawrence Barwick , Bharath Rupireddy , PostgreSQL Hackers , shveta malik 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 Mon, Feb 2, 2026 at 11:27=E2=80=AFAM Peter Smith = wrote: > > On Mon, Feb 2, 2026 at 4:32=E2=80=AFPM shveta malik wrote: > > > > On Fri, Jan 30, 2026 at 1:46=E2=80=AFPM Peter Smith wrote: > > > > > > Hi Vignesh. > > > > > > Some review comments for v38-0001. > > > > > > =3D=3D=3D=3D=3D=3D > > > > > > 1. General. Patch structure > > > > > > This patch set structure seems muddled to me; I think patch 0001 > > > requires proper handling for EXCEPT (partitions), otherwise, it canno= t > > > be independently committed. > > > > > > It's my understanding that the goal is to try approach #1, but if tha= t > > > proves too difficult, then the fallback would be approach #3. Yet > > > AFAICT this patch 0001 is neither -- I have no idea anymore what patc= h > > > 0001 does for partitions; IIUC it looks like just old partition logic > > > from a few versions back (???). > > > > > > Personally, I felt it would be better to combine 0001 + 0002 (approac= h > > > #3), then 0002 would be a patch that *replaces* approach #3 logic wit= h > > > approach #1 logic. That way, 0001 is self-contained, and 0002 is an > > > evolution of the feature. > > > > > > > I agree that the current patch structure is hard to follow and doesn=E2= =80=99t > > add much value, since patch001 isn=E2=80=99t aligned with a specific ap= proach. > > How about this patch structure: > > > > patch001: Implement EXCEPT syntax and CREATE PUBLICATION changes. This > > includes all changes required to correctly populate > > pg_publication_tables and pg_publication_rel. > > > > Expectation for patch001: > > When this patch is applied on its own, CREATE PUBLICATION command with > > the EXCEPT clause should work, and the appropriate entries should > > appear in pg_publication_tables/pg_publication_rel with the except > > flag set correctly. No publishing expected in this patch. > > > > patch002: Enable publishing and subscription support. > > All changes required to make subscriptions work should go here, includi= ng: > > --table sync and other subscriber-side changes > > --pgoutput logic to determine which tables are published > > > > Expectation for patch002: > > Changes should be published and replicated correctly to the subscriber. > > > > patch003: pg_dump, tests, documentation, etc. > > > > All of the above changes/patches are intended to support Approach001. > > > > Approach003 has a limitation in that it allows 'only' ROOT table to be > > specified in the EXCEPT clause. If tab_root is listed in EXCEPT and a > > user later attempts to attach it as a partition of another table > > using: > > 'ALTER TABLE root ATTACH PARTITION tab_root', we would need to block > > the ATTACH PARTITION command. Given this, we should first try to > > implement Approach001 and evaluate its feasibility. If it turns out to > > be impractical, > > we can fall back to Approach003 or consider other alternatives. For > > now, the Approach003 patch can remain on hold. > > > > Hi Shveta, > > Your split proposal sounds like an improvement. > > Personally, I feel each patch should be *self-contained*, not only > because then it could safely be pushed independently, but also because > I normally work 1 patch at a time > - apply 0001 / review 0001 > - apply 0002 / review 0002 > - etc > > Tests: > IMO if patch 0001 does something then it should also include the > necessary tests for that "something". Then patch 0002 adds something > more so the 0002 tests should evolve to add a few more tests to what > were there for 0001 etc. > IOW, I don't really want to be forced to apply everything in order to > run the tests for 0001. +1. we should be adding tests in the concerned patch > > Docs: > Again personally I prefer everything *self-contained* for 0001 would > have docs for 001 etc, so I can focus on just one improvement at a > time, but I'm OK with docs being kept separated if others prefer it > that way. I think splitting the doccould be challenging. We can start by keeping it in patch003, and once we have better clarity, we can consider splitting the doc if needed. OTOH, each patch=E2=80=99s commit message should clearly state its purpose,= so the EXCEPT concept can be understood without referring to the doc coming in later patch. thanks Shveta