Hi all >On 2026/08/28 13:54, shveta malik wrote: >> On Fri, Aug 28, 2026 at 9:04 AM Peter Smith <[email protected]> wrote: >> >> Hi. >> >> While reviewing another thread, I had cause to enumerate and try many >> dozens of CREATE PUBLICATION clause combinations. I found one >> combination that gave an unexpected result. IMO this a bug: >> >> CREATE PUBLICATION ... FOR TABLE s1.parent, TABLE ONLY s1.parent; >> -- No error? First wins. Behaves like FOR TABLE >> >> CREATE PUBLICATION ... FOR TABLE ONLY s1.parent, TABLE s1.parent; >> -- No error? First wins. Behaves like FOR TABLE ONLY
I also think this is a bug and should become an error. Specifying both TABLE and TABLE ONLY does not make much sense. > I also feel that it should be an error scenario. Let's see what others > have to say here. > > While validating the patch, I figured out that this simple scenario, > even without inheritance created, also triggers the error: > > postgres=# create table tab1(i int); > CREATE TABLE > postgres=# create publication pub1 for table only tab1, tab1; > ERROR: conflicting ONLY specifications for table "tab1" > > I see that 't->relation->inh' is true for anything which does not have > 'ONLY' specified with it. It makes sense, too. Even though tab1 > doesn't have any descendants yet, it may have them in the future, and > then this publication can break silently. So, it's better to reject > such a publication at creation time, even for tables like tab1. For a plain table with no child tables, I also feel it make sense to make this error. It seems to me a publication table is registered in pg_publication_rel based on the definition when CREATE PUBLICATION is executed. So, even if the plain table gets a child table in future, it would not affect the publication definition. Having said that, this should become an error. The fix and test code look good to me. I also noticed that you improved the doc explanation regarding the relationship between ONLY clause and partitioned table. How about splitting this doc patch to a separate patch and thread? The doc fix seems good to me but it's not directly related to the main issue in this thread. By separating the thread, I guess it would get more attention and be easier to commit. Regards, Takeshi Ideriha
