On Tue, Aug 18, 2026 at 1:34 PM Peter Smith <[email protected]> wrote: > > Hi Vignesh/Nisha, > > IMO, it feels like these patches are doing too much work trying to > protect the user from themselves, and it is even making some > combinations difficult to specify. > > Also, there is a lot of logic and many lines of code now just for > checking publication command "inconsistencies".
After looking at v28, which has introduced new error scenarios as concluded earlier, I completely agree that the code has become quite complicated, especially when identifying Case 2 mentioned in [1] (cross schema references when both schemas are mentioned in publication) [1]: https://www.postgresql.org/message-id/CAJpy0uAqvPBbQGfBmXVn2iugtTkw4uS7_H%3DXcGuzdgPNMsQOag%40mail.gmail.com > ~ > > Anyway, I wanted to step back for a moment to reconsider if all this > jumping through hoops is really necessary... I'm not sure that it is. Yeah, looking at the code complexity, I would also like to step back and rethink. > I've been wondering about something much simpler. There are just 2 rules. > > RULE 0: Assume the user knows what they are doing! > > RULE 1: Fine-grained clauses take precedence (so anything the user > says about a TABLE takes precedence over whatever they say about a > SCHEMA) > > e.g. > > FOR TABLES IN SCHEMA s1, TABLE s1.t1; -- OK > Okay. Current behavior is the same. > FOR TABLES IN SCHEMA s1 EXCEPT(TABLE s1.t1), s1; -- FAIL this is a > self-conflict because the same schema is specified 2 ways Okay. Current behavior is the same. > FOR TABLES IN SCHEMA s1 EXCEPT(TABLE s1.t1), TABLE s1.t1; -- FAIL > this is a self-conflict because the same table is excluded/include Okay. Current behavior is the same. > FOR TABLES IN SCHEMA s1 EXCEPT(TABLE s1.root), s2 -- OK the tree > exclusion takes precedence, so s2.part is also excluded even though > rest of schema s2 is included Okay. Currently, v28 emits an error for the contradiction that s2.child is excluded through the hierarchy rule but included through schema inclusion. And emitting that error required introducing a lot of code complexity in v28. So we can think about changing the behaviour to accept rather than emit an error. > FOR TABLES IN SCHEMA s1 EXCEPT(TABLE parent), s2 -- OK the hierarchy > exclusions (default *) take precedence so s2.child also excluded end > though the rest of schema s2 is included Same comment as above. > FOR TABLES IN SCHEMA s1 EXCEPT(TABLE s1.parent), TABLE s2.child -- OK, > hierarchy exclusion would normally exclude s2.child too, but the user > says they want to keep it so it stays Okay. Currently, it emits an error for the contradiction that s2.child is excluded through the hierarchy rule but included explicitly. No code complexity is involved in identifying this case, nor is it a new error addition in v28. But if we plan to change the behaviour for the case 'FOR TABLES IN SCHEMA s1 EXCEPT(TABLE parent), s2 ', we can change the behaviour of this command too, so that both are in sync i.e. no error on such contradictions. The only thing to notice here is that when 'pub_via_parition_root' is true, even though user has included 's2.child' explicitly in publication, s2.child will still not be published. But this case will not be any different from existing case on HEAD where parition alone is included in publication with publish_via_partition_root=true. Example: create publication pub1 for table s2.part with (publish_via_partition_root = true); > FOR TABLES IN SCHEMA s1 EXCEPT(TABLE ONLY s1.parent), s2 -- OK, the > hierarchy exclusion does not go any further, so s2.child is published > along with everything else in s2. Okay. Current behavior is the same. > ~~ > > - Won't this reduce the amount of implementation code needed? > - Won't this simple precedence rule be easily explained/documented? Yes, it will. > Thoughts? > Given the code complexity of the error scenarios added in v28, I think it is okay to take the approach to accept these scenarios rather than emitting errors. But we can wait for others' opinion on this. thanks Shveta
