Re: Publication of same parent table with ONLY-ness mismatch should error

Hi all

>On 2026/08/28 13:54, shveta malik wrote:
>> On Fri, Aug 28, 2026 at 9:04 AM Peter Smith <smithpb2250(at)gmail(dot)com> 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