Re: Skipping schema changes in publication

On Sun, Mar 1, 2026 at 6:21 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> On Sun, Mar 1, 2026 at 5:52 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Sat, Feb 28, 2026 at 7:37 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
> > >
> > > This occurs because when ONLY is not specified, the table t_inh and
> > > all its descendant tables (t_inh_c1 and t_inh_c2) are added to
> > > pg_publication_rel at the time the publication is created. Replication
> > > then proceeds strictly based on the entries in pg_publication_rel.
> > > There is no explicit parent child mapping maintained for these
> > > relations in the publication catalog; each table is treated as an
> > > independent entry.
> > > When "ALTER TABLE t_inh_c1 NO INHERIT t_inh;" is executed later,
> > > t_inh_c1 is not automatically removed from the publication. Since it
> > > was added as a separate entry in pg_publication_rel, removing the
> > > inheritance relationship does not affect its publication membership.
> > > I'm not sure whether this is the intended design or an unintended side
> > > effect. If this behavior is not expected, we can address it separately
> > > and adjust the implementation accordingly.
> > >
> >
> > So, the similar case for partitioned table works because there we add
> > only root partitioned table in pg_publication_rel. I understand that
> > current behaviour for inherited tables (each inherited table is
> > considered separately after being added to the publication) is because
> > of the existing design and should be changed separately, if required.
> > I haven't checked whether it is possible to change this behavior but
> > it appears that we should try to investigate and see the possibility
> > of fixing it separately.
> >
>
> IMO, we do not need any change in behaviour here.
>
> For inherited tables, publication membership is materialized at the
> time the publication is created and is not dynamically derived from
> the current inheritance hierarchy. Once inherited tables are added to
> a publication, each table is treated as an independent publication
> member going forward, regardless of subsequent changes to the
> inheritance relationship.
> This differs from partitioned tables in PostgreSQL. In the case of
> partitioning, publication membership is derived dynamically from the
> partition hierarchy. Partitions are not independent logical tables;
> they are structural components of a single logical table. Thus
> attaching or detaching a partition automatically impacts publication
> behavior. IMO, this distinction between inherited and partitioned
> tables is fundamental to their design, and thus should be preserved
> as-is, including in the context of publications. Or let me know if my
> understanding is not correct here.
>

Okay, noted!
My main concern is that whenever a user attaches or detaches a child
table, they must manually reset the publication EXCEPT list if they
want the table to be replicated. The doc under “For inherited
tables...” --

“If ONLY is not specified, the table and all its descendant tables
(if any) are excluded.”

does not clearly state that this applies only at the time of
CREATE/ALTER PUBLICATION, and that users must explicitly handle
changes if the inheritance hierarchy is modified later.

I am fine with updating the doc accordingly.

--
Thanks,
Nisha