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". ~ 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. 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 FOR TABLES IN SCHEMA s1 EXCEPT(TABLE s1.t1), s1; -- FAIL this is a self-conflict because the same schema is specified 2 ways 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 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 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 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 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. ~~ - Won't this reduce the amount of implementation code needed? - Won't this simple precedence rule be easily explained/documented? Thoughts? Of course, I might have overlooked some fatal flaw, so feel free to pop this thought bubble. ====== Kind Regards, Peter Smith. Fujitsu Austalia
