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 1vpgtN-00DfdA-11 for pgsql-hackers@arkaria.postgresql.org; Tue, 10 Feb 2026 06:06:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vpgsL-00DxnQ-31 for pgsql-hackers@arkaria.postgresql.org; Tue, 10 Feb 2026 06:05:29 +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 1vpgsL-00DxnH-15 for pgsql-hackers@lists.postgresql.org; Tue, 10 Feb 2026 06:05:29 +0000 Received: from mail-pg1-x529.google.com ([2607:f8b0:4864:20::529]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vpgsI-00000001O5y-448s for pgsql-hackers@lists.postgresql.org; Tue, 10 Feb 2026 06:05:27 +0000 Received: by mail-pg1-x529.google.com with SMTP id 41be03b00d2f7-c6dd5b01e14so197374a12.0 for ; Mon, 09 Feb 2026 22:05:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770703525; cv=none; d=google.com; s=arc-20240605; b=EUCJWNik6Jkf1+F7dRs2P7qV0yiATTxfzCid43hl44Z7GhpLlMjC8VIljqu5pYo7h5 EhXhLM32K+i0Dpn2OgDR+y6DCoHDjAu35sJaLN+ENybkYaOzUEZpOuzcRLvjaKnehrWA hIFan2r5LfWFYQkQODfA4uIvDzhXNItdDdeBP+HMbTYs/aofkbJsWxcrmr5B1jqn/8E+ dK+sdOb7G9Tm7uYwi78mHV+AgLWoV8/YPzgQr/BTZdStnmrbmf09lKAgiIGqX6MdHn7t XCH0py4jvMujxu2XTbJJa2nQqdySglGRszi6YlKxH+A/BWC4RH3V4csdRLouabPHziLk uEAQ== 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=i0GBtMHdKMPBebrP7CACVuev/oyHs8XXGgvPTIU5xmA=; fh=fXwf4sI+UXjGmfqCNqAeaFVh7u8nhfFGT5mwIhV3JjA=; b=ANVKoqgd63NNBgjwJ2Nymdrcwz1i8qZfZpSlr6+Rgk80ekF/3bR1hYGa5IbyTv7l64 PTLosibFWk984SGmXDC2JW1FYMiyMmRgUC+r+Fgto7OZjmyN7LiujhOOuOv7sLEF6Lvl BQEtlCQnmPdW7rCzRezN5g4u8/sRSLbslFDytnKdUS/h6finfpkkxWHUV6ahXUDudGuh tB5Gd1E2g6QlFm9BdZZlDdkFGGQE67BYcTp6kOD3iYclswNjDZsfy0Cp+z1zE9wJ2Y0B kzhlRMWacEw7jEOyNxi4znPdSD878iGSr/MWsWXX5GSdFBmEuc6UGudIDm3oVWGyRNKj EDEA==; 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=1770703525; x=1771308325; 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=i0GBtMHdKMPBebrP7CACVuev/oyHs8XXGgvPTIU5xmA=; b=hol8IfApRTjnECnJTDtg1FS+bLmsX4kbcStsIFs0sy2XZQgu/cgOI+OXtY+JjkUddz WVtvoEzoQt9xiI38NdYw6it2TElr0OkrVSiFF+3IplQnYDwSfe+VLo9Wcdx/Sq8jVFSi UjlLn2KrbyM/U8FzJRihTbF5e8dgyrIWG1BpvJisNMBs3ukjVyzB3mzQiWHKNR3bxsKn t8UqWZucq0V8tZSoOaqpeq6y5DQhFcuBjctXW0uq0qWDFt4JC3dOmxNjXdvgIh9prCK5 maNd9VG+AYpzxKJPYCqApJJjqgKva9UYcHanUUYRlf+2s5rif5pj0nM01MbcCzFPLyEB HC+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770703525; x=1771308325; 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=i0GBtMHdKMPBebrP7CACVuev/oyHs8XXGgvPTIU5xmA=; b=q2raTBmeTqfQxV0aU8VF5kFPgmz8QH5lem9VPK0SuC1bwCFPj2mRTATvGMCv71I1zB f/3x5TrawHzt2d2MnmUTnKcAalmxOC4Jf3hnNdgnq390t7BgZzB+xXvU3QqpQPqKriHI NfrAz9M2ddCZ4RY0hW9glZgWpp6id8cUrtrDhnlFt3AkV72GDvdUc2eDnMzFVZ/9rARo HQ/gBwCufTddOwqFfBoXWb3w4Hl4s4mSbJnU7hmeG13qZlal/gVMuimIPZ7+3a4YNgCd 65/q4xTssRr5z6B/2WTgW/eoVbzRgVA9F93Tv9cpyZi+zQE5rfjziTOpxARKjwKEi/vg NoLg== X-Forwarded-Encrypted: i=1; AJvYcCUhd+nB+Z6T/tEQWLXkqKu6rtx+535v2URVN1gMk5GMpKikbh2V32wfR4slIMNznQC4EryaRrIhfQoHXo9J@lists.postgresql.org X-Gm-Message-State: AOJu0Yy/amxF42O+86suL8cVtVfoB+befRB2ehoVlGfhYHa19FsIkDdn iX+VHtMGhOGmkkGpDrOnRwKuHa1YEaxRSRINoyAdDbNudqEeBSgQICOH/2f37It8q9rVMiGgHlI 4o1UpgZBphbhq+X6xxRKWiaFXQkywXLM= X-Gm-Gg: AZuq6aJqbbDYrrKfpv9glXwjk9Qv60Pr3ozqAz3oPOgYeGFJzokPSsYfhFCw+ttSKDZ WohHc5tOvlbBEC+9Tn37ygVV7jY1JtAb8FqYn1SgtlFtPXZolCAmyvcuk9ID49aiqKKVKYR2la1 ppYsMex3zzbt7yOMMx5vUdNW3SaDq0kCgM5VFbo5/gAWmUoFAKD7uO3ROOuXiYucBiMMBXoRreN nYKniM3D79lLBxO5tUu8tufTW2mNQsioDsdMp54pM9KaePRAcZdbsijcAdtK1phCGiBdi+bGw9w nBaEcjS6Jdi1jdGEWLIclXGg4bZad08H4HT1k3f5THelXShXrne1EA== X-Received: by 2002:a17:90b:5348:b0:340:4abf:391d with SMTP id 98e67ed59e1d1-354b3bf101amr13516832a91.16.1770703525138; Mon, 09 Feb 2026 22:05:25 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Tue, 10 Feb 2026 11:35:13 +0530 X-Gm-Features: AZwV_Qhi_7wDmsAWTXIwyq3GIX446BTpaUJ1URQdpUj08cCru1DBAhL2ooH4KJs Message-ID: Subject: Re: Skipping schema changes in publication To: "David G. Johnston" Cc: Amit Kapila , Peter Smith , Shlok Kyal , vignesh C , Dilip Kumar , "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 9, 2026 at 11:52=E2=80=AFAM David G. Johnston wrote: > > On Sunday, February 8, 2026, Amit Kapila wrote: >> >> On Mon, Feb 9, 2026 at 6:41=E2=80=AFAM Peter Smith wrote: >> >> > Hi Amit. >> > >> > I understand there can be some tricky scenarios where partitions are >> > involved, but I was not sure why "pub1: FOR ALL Tables EXCEPT (tab1) >> > and pub2: FOR TABLE tab1" is an example of contradictory behaviour. >> > >> > Consider if the publisher has 3 tables tab1,tab2,tab3: >> > Here, "pub1: FOR ALL Tables EXCEPT (tab1)" is like a shorthand for >> > saying "pub1: FOR TABLE tab2,tab3" >> > So what's wrong for the subscriber to combine pub1 and pub2 in this ca= se? >> > >> >> It is because one of the publications (pub2) indicates to include a >> particular table tab1 and the other one (pub1) to exclude the same >> table. And things become much more complex when the Except list >> contains partitions as shown in Shveta's example. So, I think it makes >> sense to keep things simple at least for the first version, we can >> consider to uplift this restriction if we see some use cases from the >> field. >> >> > > I=E2=80=99m with Peter here - I do not think it is wise to expose the exc= eption listing outside the publication. Publication combinations should be= purely additive in much the same way grants are in the system. Except lis= ts are internal shorthand for describing the positive list of tables a publ= ication makes available - all tables except. > The earlier case - pub1: FOR ALL TABLES EXCEPT (tab1) pub2: FOR TABLE tab1 WHERE (c =3D 99) seems a valid scenario, and we are currently evaluating its implementation feasibility under Approach 1. OTOH, subscribing to two different publications that are both defined as 'FOR ALL TABLES' but have different EXCEPT lists introduces unnecessary implementation complexity without a clear business use case. This becomes especially complex when the publications exclude different partitions of the same partitioned table. For example: pub1: FOR ALL TABLES EXCEPT (part1, part2) WITH (publish_via_partition_root=3Dtrue) pub2: FOR ALL TABLES EXCEPT (part7) WITH (publish_via_partition_root=3Dfalse) IMO, there is no clear need for a user to create multiple 'ALL TABLES' publications with different EXCEPT lists and then combine them at the subscriber level. Given this, to keep the patch simpler, we plan to emit an error for this scenario (multi-pub EXCEPTs case) for now. If a valid requirement emerges in the future, we can revisit and consider supporting it. thanks Shveta