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 1wh3I5-0001H8-2p for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Jul 2026 10:44:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wh3H4-000OFz-0M for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Jul 2026 10:43:34 +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.96) (envelope-from ) id 1wh3H3-000OFr-2X for pgsql-hackers@lists.postgresql.org; Tue, 07 Jul 2026 10:43:34 +0000 Received: from mail-pj1-x1035.google.com ([2607:f8b0:4864:20::1035]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wh3H1-000000001Mt-3SzQ for pgsql-hackers@lists.postgresql.org; Tue, 07 Jul 2026 10:43:34 +0000 Received: by mail-pj1-x1035.google.com with SMTP id 98e67ed59e1d1-3825c406ffeso3203983a91.0 for ; Tue, 07 Jul 2026 03:43:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1783421010; cv=none; d=google.com; s=arc-20260327; b=ijCBCT0gTT2O457xk+7SKAzaJU6Zr/wB7ULjMeGZSL6dHKUuVvS6/qwRIAovLKVUTk wTEoBP0WmarfQaCyFGEybKeO+URhLSg1Y6mAoClvMAqakM/qk2MznGuKGecZ21K5A1z1 7Tae6P3/C9cHjjMP6Li30YAMYSUUoRiIk6LkYOacZipmGMMecack+j3O8AeKsf+yIfQr xQ+A/UnDpSzDGrj3BVN1E6kqfA4OnfM1sxbPQnh4CLwW4WqqtQh4OhM9DIi6vw8E5zQJ zo7zvV2Q3MdAU3utsQ4UEaG/A4noyMe6ji2jdLCZMN70F6mhzvwADwR5Sb6qRWmM+STy zGdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=DPT2JARg8Bhh0kXi9qvtnKhIe+KQ0iqJKEgZ3PFzSgE=; fh=fXAOq68pQWP0vDBqzlzi4SQud1DmSiFDLXzOjAzihks=; b=Z8C/vthWvSYXqsGYhijis1vb+YC3OBw1VsdG2SEu8R65LMCWIXxbJavI8jzhPg8tlI zdNK99efaBQw0loG0RXOxnOYdJNSe5SirtrayFMb6S0/a+DTmh/ax+YqJmkZH3g0qyMO wPMhpKb2+Sys+Vu6PcerejAJK/OC1Jxyh3ttYHq6sHMEF0zieBOHiotgdJZBXHBk1xvF p3FpAB5LYxDiSMKsuYj2fs87rPUpx9jbQM+q3S8xZJK9sZT4F9ERw0VLGcZ9FzjCbh/T B6RBvRlddYUrej5WlPXJI/wqWE7Jh8JjBs9SYgcZsujl1PYTYW42WCwlWG84ZogI1Y5p KkgQ==; 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=1783421010; x=1784025810; 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=DPT2JARg8Bhh0kXi9qvtnKhIe+KQ0iqJKEgZ3PFzSgE=; b=s1272VVRFnk4oaV+L3Y10yLQ8JLoGUj5UuRw4H87Vt5taE7dGdSASuhkszib+hn+bm yQa9IpKfj/uKUihKeMc9yH3V9dgia8y5jbL3dFSfuD0rgnokpqbGuCTDdGG0pPbaPwjL H16r5exX1AwpS+Whc4FwqUJiDWR8UFeJszWQ+rXtNcJUX4BmuFaNDxQ1u4fOAOxW5tjF f3x97y7wYM+3hUFvQtRZl7SGyCKzCBQUDsP3lkGP0XXNFVb80mDLNwycfX174LnP+pa5 CVLfU5GmnPPt7jH0wf6PP4r+aFhnrSELXfJW9yDGL36qaw5ndkyvD/mlZoR9wrEskCiT 69YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783421010; x=1784025810; 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=DPT2JARg8Bhh0kXi9qvtnKhIe+KQ0iqJKEgZ3PFzSgE=; b=XVkGShqbaoMx65KOx0zSp+vf+0I7xTkvf8KejHW+mZkIdHhNRvLXkV3oLAfumfwsro NJ0EwkF3UhKzZeNke3YURLMXafhxUU/Z37BZd1Hme467+uQ7uHJ77s90RGeC8lIpf1OE BCyxdFoC6n0P9ED2XiWe9Z/zIxO1DiQjvs05AvyRf0eHdgv2xVwIOzmSTT30AA5e5BRi WVvVfLL4TWwHT+kKXCNU1Qe2FYwSpUjBZbm+zLarsFGRmA8kVXRDFMO6HL8d50KN8kRt 2Cnk8nU1aqoELNlnALi5YzI0jYvIEwiubWvXQjBn1S5kqOhpE31B+08ftEeIm1u6XJfm s/0w== X-Forwarded-Encrypted: i=1; AHgh+RqI7Knny/WSpW2FETIB+MsNFVLOQ6ldHi7rOvD4AdbE57VxXpZY9bB6f9ZqCk4JwhmyDbqQKBv+TohCxoJC@lists.postgresql.org X-Gm-Message-State: AOJu0YxFDCkHV/CzzrvZ/X1FpQkSfRO1/nIaWDmfjbTwTXjFdeh4sG/o 5Rj4KYGuncOCi09KB+zMssQgnvQuWadrG8gy9eCBM5VRpF5gggZxOBi0ZYWIFA1Z4FHh2SBxa82 VURZHKS3aII3Rdhfk5yiCX0oHvcyNiiw= X-Gm-Gg: AfdE7cmdkM5m9YHyciAy3RlWkBnyiglIe6Skg8+hMOdrh8GK9cwMq+tTLD/f40ZmGcS RBQ7k1u+OLs8mvLx3V8uayasDcrDSA0GGjMlmR4e/xEbPd15ov8qvT9Y+bXfccNkWb6odQrQbPI XQbdG8jRyXmR+cSMiTC0HLpAbC9+WT6oIAlOwah6nfjawzKeYurfnm91vxdEay0CBt5FTWGdCAy 3KHC6oK4oHb2Guxl3nhMsSN+z01dTO4peh4oDl9od/7rsj5Eu9G7PYzVBVBU7azVwyf8IHsxbVy VWBTiV90giNbtonDRsu+8MMa57I+Ah15cSk5dBnu9js= X-Received: by 2002:a17:90b:2551:b0:381:a766:efc9 with SMTP id 98e67ed59e1d1-3875528af3bmr4536960a91.7.1783421009872; Tue, 07 Jul 2026 03:43:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Tue, 7 Jul 2026 16:13:17 +0530 X-Gm-Features: AVVi8CeuI5_bELc2FeVO-mbLjGadvjPOusbYZ72C5OVzt6lOjMzxeP5kSxDC2fY Message-ID: Subject: Re: Support EXCEPT for TABLES IN SCHEMA publications To: Nisha Moond Cc: Peter Smith , Amit Kapila , Zsolt Parragi , pgsql-hackers@lists.postgresql.org, 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 Tue, Jul 7, 2026 at 2:31=E2=80=AFPM shveta malik wrote: > > On Fri, Jul 3, 2026 at 10:15=E2=80=AFPM Nisha Moond wrote: > > > > > > postgres=3D# alter publication pub2 add table t_part_p1; > > ERROR: cannot add table "public.t_part_p1" to publication "pub2" > > DETAIL: Partition ancestor "public.t_part" of table > > "public.t_part_p1" is currently listed in the EXCEPT clause of the > > publication. > > HINT: Change EXCEPT list using ALTER PUBLICATION ... SET TABLES IN > > SCHEMA ... EXCEPT. > > ~~~ > > Thanks. Do you think we should restrict this case too? To me, this > seems like another variation of the above where conflicting entries > are given at the time of sub-creation itself. The root is excluded but > parittion is included . > > postgres=3D# create publication pub1 for table s2.tab_part_1, tables in > schema s2 except (table tab_root); > CREATE PUBLICATION > postgres=3D# \dRp+ > Publication pub1 > Owner | All tables | All sequences | Inserts | Updates | Deletes | > Truncates | Generated columns | Via root | Description > --------+------------+---------------+---------+---------+---------+-----= ------+-------------------+----------+------------- > shveta | f | f | t | t | t | t > | none | f | > Tables: > "s2.tab_part_1" > Tables from schemas: > "s2" > Except tables: > "s2.tab_root" > Since alter is blocked for above case while create-sub is not, I had a look at the new check added in check_publication_add_relation a) The check introduced in this function for partitions/ancestors is sufficient for cases where an except-list is already present, but not for cases where we are in the process of adding one. Thus the create-sub scenario above is not covered by this. b) Also the new check in check_publication_add_relation() gets and traverses complete list of ancestors + List *ancestors =3D get_partition_ancestors(relid); + + foreach_oid(ancestor, ancestors) Isn't getting root (llast_oid(ancestors)) and checking that alone in EXCEPT list will suffice? Or am I missing something? thanks Shveta