Re: Added schema level support for publication. - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Added schema level support for publication.
Date
Msg-id CAA4eK1JcXG3stqncfB6BjcXW+ao1vg=5q6YJsvjDoY=+AvT1Lw@mail.gmail.com
Whole thread Raw
In response to Re: Added schema level support for publication.  (vignesh C <vignesh21@gmail.com>)
List pgsql-hackers
On Mon, Aug 9, 2021 at 11:31 AM vignesh C <vignesh21@gmail.com> wrote:
>
> On Fri, Aug 6, 2021 at 2:00 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > ---
> > Suppose that a parent table and its child table are defined in
> > different schemas, there is a publication for the schema where only
> > the parent table is defined, and the subscriber subscribes to the
> > publication, should changes for its child table be replicated to the
> > subscriber?
>
> I felt that in this case only the table data that is present in the
> publish schema should be sent to the subscriber. Since the child table
> schema is not part of the publication, I felt this child table data
> should not be replicated.
>

But, as point out by Sawada-San, the same is true for FOR TABLE case.
I think we should be consistent here and should publish the data for
the child table if the parent table's schema is published.

> I have kept the above same behavior in the case of publication created
> using PUBLISH_VIA_PARTITION_ROOT option i.e the child table data will
> not be sent.  But now I'm feeling we should send the child table data
> since it is being sent through the parent table which is part of the
> publication. Also this way users can use this option if the user has
> the table having partitions designed across the schemas.
>

This sounds fine to me.

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Re: Bug in huge simplehash
Next
From: "Drouvot, Bertrand"
Date:
Subject: Re: [bug] Logical Decoding of relation rewrite with toast does not reset toast_hash