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 1whO1P-000Bza-2W for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Jul 2026 08:52:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1whO1O-006GXH-00 for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Jul 2026 08:52:46 +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 1whO1N-006GX9-1g for pgsql-hackers@lists.postgresql.org; Wed, 08 Jul 2026 08:52:46 +0000 Received: from mail-pl1-x633.google.com ([2607:f8b0:4864:20::633]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1whO1M-000000007rv-1Dtt for pgsql-hackers@lists.postgresql.org; Wed, 08 Jul 2026 08:52:45 +0000 Received: by mail-pl1-x633.google.com with SMTP id d9443c01a7336-2c7c61b5292so8730925ad.0 for ; Wed, 08 Jul 2026 01:52:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1783500763; cv=none; d=google.com; s=arc-20260327; b=I8qtVHKC4eT4/Xvo6Uc06chnU+rDTHCAuBYXwElsol4qsxiQbkGWWCSIfmO7kfX0Nu sdN8w6IrxmbR098cESP7ZaapsZaSGprEoOVYdqoHy4lwC72Xh55s2qAQfmypJKw3ZcDk REREUzpqe1ZOcZp9yAgeWUc0F9S3F5NvxgFRxcvwLrsfKf+LcLafJTMtO7Y/FOJFeT0x YPHYtedB7wWgf47AiUEJF/1F9RkIsAJbWZOWAhGkyLr3z7fK+3Q0MR3tzspNCxTHCz+t ThW/j6ZqgT4W0cFLrsDLQiew+I6Qg2fs9F/dzH3nU4qZIHURajHwS1TW1qH9i9/lpKd1 QWFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=kx31uuR+kLJKRE+OKsrF8w9fWSJsJgEkeVe8lI0KLhI=; fh=jDuwbzoPlfDJ/y+aGnxVNjxMTOVPUH+Ku3izHPS4zmE=; b=JLU2YNSzxDxPSHwDpP86p7CMJmt2YhQliBPTNVpHvcrQuovZQgY5N8lQr7EbAzU+hD o3187oIH4IE0t76364Uiz2dl5fEZzUKTinhnJT/JMe0aN+TS4Mqyq4bjodflEbxXaUw7 NA53ErDIvBNI9Wv3T5w/u2gGRbfREFei9P/8oSGmL0oxj1Vug/pdWuGZaVQU+6Uie5Ca ncL/oTFiY4OUpUETWAaDNi3WOktBPt3UOfIF5GADw8UnPJ8hmIs3TOWxwhcQeI22z7ao ise0DwOTLe9cZCSYnjEGKA23gtpOoe8E5s9J++6irSxnWDYPyT/9zq9uaic+xRJu7e6i HRsw==; 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=1783500763; x=1784105563; darn=lists.postgresql.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=kx31uuR+kLJKRE+OKsrF8w9fWSJsJgEkeVe8lI0KLhI=; b=TH5m4CrIJ7f0r5DH4dTCRRgNZiaLUrnRm0HvNIC4lDi6JZPeMjSR2rg/lg+xFv8yB8 3nZRR4lKvSt/2Z7LD5hsHueFlIUFazQ3822sk+z/1Os9b+R+jbrszZfpF0wiBML/zPfm OADKC9C/CzeSzWLl138TEimLzCMSdLcIJsUj1C4xWZYHrRSSKxPH3sIq5FUCk+/WurlQ Io2NnwMY8tUlIsIfEJOZz12MYFeTTP0k7awaFnj/qqbzURUGAVYhfQBdekNmbjH0xLYr OxRSyiLC9hF0x97BQ8I66Ff3SRXXnzUQCUTO0pIYyEP+YmcrRK6eO/7WDMiaJKGNUrKi ScUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783500763; x=1784105563; h=content-type: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:content-type; bh=kx31uuR+kLJKRE+OKsrF8w9fWSJsJgEkeVe8lI0KLhI=; b=dXa5KE5aFwv/6ZVGVkISBQxpe8XW09YacOaEN/E9ZrB79sldXn8UNOJ3MGFWQf5aj4 RflDzB3zDoyM/5NuPCxFZAVyPAlDzMqYqdIoSvfFSE0OswxoXQBWV0Ue2tokXR/f/ZId 0J9XJGBr3fOFpFWGcsj9UgT0N9tqo0bbYPKEHKSi2Dui8+kDyGtzk6R2LUPVzET2cF0X M1uRfHvDSuZHIOjgtFdIQsgNO91fyTfWWkCv287lsHGSbBUZ7BAJ6mhDSuJ4w/ipvLoo rPW/g+enCBaBp5gF+2lS2FS6k3KIOtBfqihO1UHc99x7zVbzsfkP1joAZ1Qu4oiHqr3V Di5A== X-Forwarded-Encrypted: i=1; AHgh+RqIlX1uo5f7XoiOjH7iMp0mc0tuqwYAT1mNCMgfiGl9Zqp5VfsJnCIX3+urSbwdWAdL4+ucW1R4eNG9M/ZW@lists.postgresql.org X-Gm-Message-State: AOJu0Ywx6WPqDdj/QGme9vFzAWGmBK4clQKv28ZLqkSxOaFhH/Zpgg5q W8kO+pe4B9AeSkRI2K/17iPvkNytoPX847A9ir6WiIE9eCjHGvVqcofL6NUg+i6d/7P7FHlO7uE 7tL/lo3p6QEUBQYbUp+gKdQStq18pjvzETplv X-Gm-Gg: AfdE7cmdmYkP1XgTjAMhGnMmpr5UXOvs/lPtEre53zd8LD3RzTRsewySs9jjPTgE6qX YjDyRU+7vslqPyO2ubWEETdGvAXh+OamyY+oh1SifecMJgbg/xvdmdQD85JQtlNHLdUEACBUOHR +k8HILABrlav16wnwSSHLBBhesQSmZQC05R2IoFP1mAt/m4KnfNRz6FMM3faNBJsmT5doPlgfLk hgpJScA7lhoVgELfFYOYTrl0Yn5fjMyT+WBqvoRKkwEU+247dO5HjZyXw1qwZbYNnxJ+5TNuhWH R9EnIxfLcRkznyGfTqmDmFmDb/ofLsLp3wIT7C07OW0= X-Received: by 2002:a17:903:8cd:b0:2c9:e5ff:995d with SMTP id d9443c01a7336-2ccea348c05mr16739995ad.31.1783500763586; Wed, 08 Jul 2026 01:52:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Wed, 8 Jul 2026 14:22:31 +0530 X-Gm-Features: AVVi8CdElpynWaWa7wIJiiFT1cLLqNxZ_131he8K3Lw_F3fN_AYCbfqAhjA-15Q Message-ID: Subject: Re: Support EXCEPT for TABLES IN SCHEMA publications To: Amit Kapila Cc: Nisha Moond , Peter Smith , Zsolt Parragi , pgsql-hackers@lists.postgresql.org, 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 Nisha, the patch (testing wise) is okay, but some code-optimization might help. I am stuck on reveiw of GetTopMostAncestorInPublication() and all its callers. 1) caller 1: pub_rf_contains_invalid_column(): It is not understood why pub_rf_contains_invalid_column() does not pass 'exceptPubids' to GetTopMostAncestorInPublication(). Perhaps a comment will help. IIUC, a parittion (for which we are trying to verify row-filter expression) can not co-exist in a subscription where its ROOT is already excluded. This assumption will be true once you address the issue of CREATE SUB (in [1]) sent in my previous email. After that, this will still need a comment. 2) Both caller 2 (get_rel_sync_entry) and caller 3 (is_table_publishable_in_publication) are trying to see if partition should be considered as included in publication and thus are trying to see if ROOT is excluded. But the implementation is very different. The get_rel_sync_entry() does that by passing except_pubids to GetTopMostAncestorInPublication(). This except_pubids was computed for topmost ROOT of the parition in the caller and then it skips checking pg_pub_namepspace if given pubid is part of except_pubids arguement. While is_table_publishable_in_publication() does that by selecting topmost ancestor incuded in a given pubid using GetTopMostAncestorInPublication(), without consulting/computing except_pubids. And then later checks if the ancestor returned by GetTopMostAncestorInPublication() is in pg_publicaiton_rel with 'prexcept' true. IMO, GetTopMostAncestorInPublication() should itself be inclusive of logic where it filters out the table (does not return it as result) if ROOT is excluded. And even we should not be passing an argument for that (this is my initial thought). By making such a logic, we need not to bother about all the callers to see if caller has correct logic to deal with output of GetTopMostAncestorInPublication(). Can you think on this line and check the feasibility. 3) I have yet to reveiw pub_contains_invalid_column, but I have a initial understanding, that it will be similar to the case of pub_rf_contains_invalid_column. Please verify on your end. [1]: https://www.postgresql.org/message-id/CAJpy0uAuL7SqowL7T6HCELuVUr5ubwoGsjV1SQQRCXGme5L%3DpA%40mail.gmail.com thanks Shveta