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 1vmmwI-00GF7V-2y for pgsql-hackers@arkaria.postgresql.org; Mon, 02 Feb 2026 05:57:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vmmwG-00BmlW-2V for pgsql-hackers@arkaria.postgresql.org; Mon, 02 Feb 2026 05:57:33 +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 1vmmwG-00BmlN-16 for pgsql-hackers@lists.postgresql.org; Mon, 02 Feb 2026 05:57:33 +0000 Received: from mail-qt1-x82c.google.com ([2607:f8b0:4864:20::82c]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vmmwE-000000008mw-2aRq for pgsql-hackers@lists.postgresql.org; Mon, 02 Feb 2026 05:57:32 +0000 Received: by mail-qt1-x82c.google.com with SMTP id d75a77b69052e-5014600ad12so30731301cf.2 for ; Sun, 01 Feb 2026 21:57:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770011850; cv=none; d=google.com; s=arc-20240605; b=Z2MYaKUfej/CnMETZgJtPCvSK8nRGUcwz9jx27OAsQDWrs7QCR3V+T2hfVtc7Cfko7 hTCYkYaQIjUenbJdB1hMnVopcfKCztI4IHlB9Fk5P0XOJkux2oXqVlmCJiKlN3m8Evji VhYSxWrbPOQ9iinWbK+0XFd6Htxvwa689fwXXTvEER5k1eaExF6iXFDRQbrYr3wGUjn2 ctnavObozK1jDi62BusQAmbycIKLsTMtX0ZYmiZblomP5L+XyG15nnJ4t1uIbhGDG1pc jGD1n464mRI2lZfl6eyXsDjprMZbZEX/EFH7vEqkxwez6gNbJIVrwJbc5qvCJQKfHXu4 Wx4g== 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=VjZqMJWWlpTdzeHd1qVbl/y2xKmwU9I8F0EadeCzE78=; fh=u0IaFuCeBlpFdtgrvETUbkSnLkBVkiFNee7vVmP5mzk=; b=imc8fnCUs1qQtU0gDAVnkHDlzxBUIqKoeanTC3dAcR3K50ouWaWlEC4KHGRKwzCoxv UZ2HauUv+o0nQD5mU+4Wx7U3TPS84vO5NviGywf2gorocsS+4AVAoIMSD15otgW1/jcp +tWS68qrufJkIIttHyh1G4eelFdt5yTcVW5O2V1Sn5NxqjPu1vEx4GiaRv26Cn4XLQo6 E9G+H4uWDyL3kHam6Shp/Ul2rzNxn2fSdSZkM4xkNErdHPxSVj/YZJPKxhxO7SBcAdi9 GjjDkUmLDTivQaGw9kloceYiD8kyxourqlXtoAsI5UsOJwyrah5YaTjgvjio7RZk+lgl J44Q==; 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=1770011850; x=1770616650; 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=VjZqMJWWlpTdzeHd1qVbl/y2xKmwU9I8F0EadeCzE78=; b=haoWcmG8U3F7fIPMLzsjdjQgQ6xYbPlb+tj6rdmNnN/fLzxfGtBirty3ZGCM0sVCKc /dc+mktZrUK0NdwyZ5A9l6Tcwd3Jydy8kkXD7Veu47x8GvBFa1A4oU0L0RzsMk1UjUBp urY62HmwbYOy6q3Hi1WClP2lW5b7gG9b7VTfDl2WG4jxEd5sh0EFOlPHw35w4rMJr3vp p/27B4ibcgtrsAwrSEcL4m6+KPncYk8/VFlpHhvVzfNPYrKTNdY0+O9IBYAjPFBVqsFu wzjQ1GwV3Uk6Yf7xvDfY6DtiUTu1INs0FvionHWu4oJ8uMsPRADvevF7lK1dg0F40Qx5 +pkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770011850; x=1770616650; 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=VjZqMJWWlpTdzeHd1qVbl/y2xKmwU9I8F0EadeCzE78=; b=wCidZ20NnJvFv7hxe49pl7Ae+SxQNcnSaAWa0d/SHI1Wi66U0mVI3XMvNJIBPegKvY sXvVqJRfVNOgKTyiqMI5tyKnP4aLlcGNHW+50rlpaW0akqxBBcLLqrYO+KZmno6nU9yc ogQGf3zos18B6XYgLFqGpSd6dSlfo39GDFDgAWGCWoi6C1Dn+aNTUNVHA4Sm7r/9czjo YELPT9U8FrTCMfyA1iHnrdYPxmiz5oEmJQi3J+fwtA1bNopRYOFmpW6A855mDUvSbkA6 A0r2T4WCLWQdS3aroQF8NrzIoYBfmVy5dgD9064u16bhzWvNwLbYAkauj+PDMNEvMcf2 9TBg== X-Forwarded-Encrypted: i=1; AJvYcCWkPqiMs4a+iEdNvv6GkaKPwaw9D1C0tYCBYvwynVxXw7rLzSMn6E1GZFzBfOjlk+08bD8566zoNbC3YDvR@lists.postgresql.org X-Gm-Message-State: AOJu0YzKBLGHi2xuGOAzJkw1bxB8UsxJZTHTN7/maYbwA6lzP/1xHOOl Uim99iKhWaZiW6E7rk9b8KC5Tqj07scMQZQIb2Y9yWx3YdIgidGkyGobs49lvnA1vejwvG5wL00 19znCQuA5be0xadHJMCzjMnG2GZtQpnA= X-Gm-Gg: AZuq6aIRPx0xo5FWfdCf7EOu5qzudh4lfEDkeFva0+kg6zPcypxGRgc87DOCvvUByGR /Hg07ZtHudlwY+Zz+lDI2WXQuApgStg1LSm93fYfhIkakoBp+ovMDT8BtLUvDpNI8w/yx9qSCIO MAg9VSyk/Fa7zzY12irNQhUvs89+n+EZEWhf2zax2hj9GotJopC9Ioj4a3c31HrKbDegmTykIF9 GxUX3eQ9QQNfnYjtJaywc/UITvbccnyGC4Xn9vSarxk+kyMFE2uNA4mRhKrsmQowilqOsc1eDpf IEjFZdiYd+bY1zoI98tEl5im5G54DQ== X-Received: by 2002:ac8:5a11:0:b0:502:a2b2:7d21 with SMTP id d75a77b69052e-505d2131283mr133973761cf.14.1770011849657; Sun, 01 Feb 2026 21:57:29 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Peter Smith Date: Mon, 2 Feb 2026 16:57:02 +1100 X-Gm-Features: AZwV_Qi9dUxFKCaDsGPnAW5N-v2lqHTrhOar5BxLn8AKqt7kJkbFj04VjY6H8gg Message-ID: Subject: Re: Skipping schema changes in publication To: shveta malik Cc: vignesh C , Dilip Kumar , Amit Kapila , Shlok Kyal , "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 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 cannot > > be independently committed. > > > > It's my understanding that the goal is to try approach #1, but if that > > proves too difficult, then the fallback would be approach #3. Yet > > AFAICT this patch 0001 is neither -- I have no idea anymore what patch > > 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 (approach > > #3), then 0002 would be a patch that *replaces* approach #3 logic with > > 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 appr= oach. > 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, including= : > --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. 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. =3D=3D=3D=3D=3D=3D Kind Regards, Peter Smith. Fujitsu Australia