On Wed, Aug 19, 2026 at 3:47 PM vignesh C <[email protected]> wrote: > > On Tue, 18 Aug 2026 at 13:34, 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". > > I still feel we should throw the error at CREATE PUBLICATION itself. > That would make the conflict clear to the user and allow them to > modify the publication accordingly.
Okay. Noted. > Otherwise, in a conflicting case > like the following, it may be unclear whether the table will actually > be published: > CREATE TABLE s1.parent (a int); > CREATE TABLE s2.child (b int) INHERITS (s1.parent); > CREATE PUBLICATION pub1 FOR TABLES IN SCHEMA s1 EXCEPT (TABLE s1.parent), s2; > > Here, it may not be obvious whether s2.child will be published because > schema s2 is included, or whether it will be skipped because its > parent s1.parent is specified in the EXCEPT clause. > > I have tried to simplify the patch. Yes, it looks simpler compared to v28. > The new version now only has two > changes to detect the new conflicts: > a) GetExceptCrossSchemaDescendants - Collects descendants of the > EXCEPT entries that reside outside the schema of the corresponding > TABLES IN SCHEMA clause. > b) Add few additional checks to the existing > CheckExceptConflicts(renamed from CheckExceptNotInTableList) > Checks whether any of these cross-schema descendants are also being > published, either explicitly or through another TABLES IN SCHEMA > clause, and throws an error if they are. > > Please have a look and let me know whether the v29 version is simpler. > I had a quick look, it looks better than v28. I will review and validate it in detail by tomorrow. thanks Shveta
