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.94.2) (envelope-from ) id 1ueRFt-009oos-FW for pgsql-hackers@arkaria.postgresql.org; Wed, 23 Jul 2025 04:39:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1ueRFs-00HZUc-Ec for pgsql-hackers@arkaria.postgresql.org; Wed, 23 Jul 2025 04:39:00 +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.94.2) (envelope-from ) id 1ueRFs-00HZUU-3v for pgsql-hackers@lists.postgresql.org; Wed, 23 Jul 2025 04:39:00 +0000 Received: from mail-pg1-x532.google.com ([2607:f8b0:4864:20::532]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1ueRFp-000MDu-0l for pgsql-hackers@lists.postgresql.org; Wed, 23 Jul 2025 04:39:00 +0000 Received: by mail-pg1-x532.google.com with SMTP id 41be03b00d2f7-b31d489a76dso5406206a12.1 for ; Tue, 22 Jul 2025 21:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753245536; x=1753850336; 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=OD4yCTX4vOwJ3VcCYUmCZdDO3eBIjmI5TXhrMqZ1Pr8=; b=UJP8igVp3E7xPXLxIPEsfIjUWG5F1g+wzVTBYpCUPCuitjhv0VFNEUN/lGK/EWGKv9 eeQfnbGm7Aw6VtEJ3v/ARRr2BtH+VtWuLx1o+44x/KE431vM0Y0JvC7to3S2qP3Tyaie z156PoraGybk4vGT7H4hlwFf/PM1uXubPH7ZBR3m4ylyYTeRXEiB78nfdqI8h6rJGb6p IPCENpsC2wAOUVCMoXCXO36KzEo3rLepv8iS5xktm8FjKCHt1xrBYRBSYnku6ud3tK+A vn3x6aKMV60MRdzMkhDJeHHwu0DST8rAdNIo6jidhhZSn9428FuF+40C2Te7ooTU6/2H D8nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753245536; x=1753850336; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OD4yCTX4vOwJ3VcCYUmCZdDO3eBIjmI5TXhrMqZ1Pr8=; b=wVjRPjnY7Hw8itRTOeYz5cn7jzsaBMKAxhuEpwuFkLN/qt3at29pMHCWiGUHaRtzeA 0jL7NQ6O8gi8cwTNCLtDgk+rA3a9Gy6uAO+4DvqXCBcd9nFUQWj3MrMRRLCaVO13f1kR jVbwWY20bjGWbGyyofrDIk4TvFCV7QBiNrYHtG550CGqVluN/M4nHv5t+L6KokDWsUsW f5Krh5+oBfYLQB64JjoURyM7kkjVSplTIJHPH943z+LPCsSIg40QJ0oOxDoDUZxIBTWT CxEcnyt0GKPiI0YMyJL+LiBJy9RwumZCZ1TbGKmCc2QFoHwRhKpn+uxomzmv8bnS2AAm ggEw== X-Forwarded-Encrypted: i=1; AJvYcCUIY9v2eEN7dHHGf0cQG8fKCMxQu3JzRuZQ3gqzqjrpeuzuMpkMmnpVquW7frvHcKct7iXr3rMQiPnb2XQi@lists.postgresql.org X-Gm-Message-State: AOJu0YxpnKpaukQPinmPLWxakptEMgArjB0cLoVjG23jj/639ZTjcx5G 02BbxRu1e2+t9JJHhMk0EmE+ska6QNKD6S2CTfdOTzq9uMNmPcFE838wIwog9ofwKvtThPmtzaS GzfAYwAUam0tsW9bzkiLsm/bwvD59QxA= X-Gm-Gg: ASbGnctVuLczUVyT26OijMA+hKsxKz5/N7/HwaezhOkdps72Uo86axU0XbyZAHFFdQB 8/CLbm9kJlEt6vTvY6yhNUC5Pv13dtD/o5PVI6qAoISPD17C0qOU5rf07cjVDId/92CyUdvraHJ 8MZWI2b0Ar+X9BnCF3mzxqlaFA8Wm8JPP1BtENf/qnm/wBcFtFBWvQYyAFYH6ktymraEGn4FCMm 9tNeByMoA== X-Google-Smtp-Source: AGHT+IGDGYsKCNDwY555C69+Mg1dGX9A5lfuCRGAh2NNN3K9cG2WdsVW9NIBWIP3l8Uhu4/ElTtH87RawI0mgOeofKs= X-Received: by 2002:a17:90a:d60b:b0:311:f30b:c21 with SMTP id 98e67ed59e1d1-31e5082cc31mr2821476a91.26.1753245535970; Tue, 22 Jul 2025 21:38:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Wed, 23 Jul 2025 10:08:43 +0530 X-Gm-Features: Ac12FXxh8JCVYecPTohuYvmJVBSPa7LK6oZHxr0z-GlhUzNiYWba58B_cYwFXuM Message-ID: Subject: Re: Skipping schema changes in publication To: Shlok Kyal Cc: Peter Smith , Amit Kapila , "Zhijie Hou (Fujitsu)" , vignesh C , YeXiu <1518981153@qq.com>, Ian Lawrence Barwick , Bharath Rupireddy , PostgreSQL Hackers , shveta malik Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I further tested inherited tables flow as well wrt ONLY and EXCEPT, it works well. But while reading docs for the saem, I have few concerns. 1) While explaining ONLY for EXCEPT, create-publication doc says this + This does not apply to a partitioned table, however. The partitions of + a partitioned table are always implicitly considered part of the + publication, so they are never explicitly excluded from the publication. I do not understand the last line: "so they are never explicitly excluded from the publication" . But we can explicitly exclude them using EXCEPT . Do you mean to say something else here? 2) alter-publication doc says (in context of EXCEPT): "If ONLY is specified before the table name, only that table is affected. If ONLY is not specified, the table and all its descendant tables (if any) are affected. Optionally, * can be specified after the table name to explicitly indicate that descendant tables are affected." But it does not mention anything for partitions. I think we shall mention here as well that this does not apply to a partitioned table. (I tested ONLY and EXCEPT for partition-root. UNLIKE inherited tables, ONLY has no impact on partitioned tables.) 3) Shall we explain the relation of 'publish_via_partition_root' with EXCEPT briefly in docs(once we conclude that design)? Please note that I have performed all the tests (mentioned here and in previous emails) on patch001 and patch002. patch003 is not applied in these tests. thanks Shveta