On Thu, Aug 20, 2026 at 2:09 PM shveta malik <[email protected]> wrote: > > I had a quick look, it looks better than v28. I will review and > validate it in detail by tomorrow. >
The code looks simpler IMO and manageable for supporting all these contradictory error scenarios. I verified the inherited table cases alone. I have a few concerns: 1) postgres=# CREATE PUBLICATION pub1 FOR TABLE s2.child, TABLES IN SCHEMA s1 EXCEPT (TABLE s1.parent); ERROR: table "s2.child" cannot be both published and excluded DETAIL: It descends from "s1.parent", which is named in the EXCEPT clause of schema "s1". postgres=# CREATE PUBLICATION pub1 FOR TABLE s1.parent*, TABLES IN SCHEMA s2 EXCEPT (TABLE s2.child); ERROR: table "s2.child" cannot be both published and excluded Can we have a similar DETAIL message in second as well? 2) I find this case still a little ambiguous: CREATE PUBLICATION pub1 FOR TABLES IN SCHEMA s1, TABLES IN SCHEMA s2 EXCEPT (TABLE s2.child); Currently it works, but should it? a) Should s2.child be published because s1.parent is included, and schema s2 is also included, meaning cross-schema inheritance boundaries are respected and brought back in? b) Or should s2.child remain excluded because of the explicit EXCEPT (TABLE s2.child) clause? Currently, we throw an error for the reverse scenario: CREATE PUBLICATION pub1 FOR TABLES IN SCHEMA s1 EXCEPT (TABLE s1.parent), TABLES IN SCHEMA s2; ERROR: table "s2.child" cannot be both published and excluded DETAIL: It descends from "s1.parent", which is named in the EXCEPT clause of schema "s1". (Because s1.parent implicitly acts like s1.parent* and s2 is also included, meaning s2.child is available for a decision to be made). Given this, isn't the first scenario fundamentally the same kind of conflict? thanks Shveta
