Re: Added schema level support for publication.

On Sun, Jan 31, 2021 at 11:32 PM vignesh C <vignesh21@gmail.com> wrote:
>
> On Fri, Jan 22, 2021 at 10:01 AM vignesh C <vignesh21@gmail.com> wrote:
> >
> > Thanks Rahila for your comments. Please find my thoughts below:
> >
> > On Wed, Jan 20, 2021 at 6:27 PM Rahila Syed <rahilasyed90@gmail.com> wrote:
> > >
> > > Hi Vignesh,
> > >
> > >>
> > >> I have handled the above scenario(drop schema should automatically
> > >> remove the schema entry from publication schema relation) & addition
> > >> of tests in the new v2 patch attached.
> > >> Thoughts?
> > >
> > >
> > > Please see some initial comments:
> > >
> > > 1. I think there should be more tests to show that the schema data is actually replicated
> > > to the subscriber.  Currently, I am not seeing the data being replicated when I use FOR SCHEMA.
> > >
> > I will fix this issue and include more tests in my next version of the patch.
>
> Modified to handle this and also added a few more tests.
>
> > > 2. How does replication behave when a table is added or removed from a subscribed schema
> > > using ALTER TABLE SET SCHEMA?
> > >
> > I would like to keep the behavior similar to the table behavior. I
> > will post more details for this along with my next version of the
> > patch.
> >
>
> If a table is set to a different schema, after the schema change table
> data will not be sent to the subscriber.
> When a new table is added to the published schema, the table data will
> be sent by the publisher, subscriber will not apply the changes. If
> the change needs to be reflected, subscriber's publication should be
> refreshed using "alter subscription mysub1 refresh publication". This
> relation will be reflected in the subscriber relation when the
> subscriber's publication is refreshed.
> If a table is dropped, there is no impact on subscriber, This relation
> will be present in pg_subscriber_rel after refreshing subscriber
> publication.
>
> > > 3. Can we have a default schema like a public or current schema that gets replicated in case the user didn't
> > > specify one, this can be handy to replicate current schema tables.
> > >
> > It looks like a good use case, I will check on the feasibility of this
> > and try to implement this.
>
> This can be done, I will handle this later.
>
> > > 4. +   The fourth, fifth and sixth variants change which schemas are part of the
> > > +   publication.  The <literal>SET TABLE</literal> clause will replace the list
> > > +   of schemas in the publication with the specified one.  The <literal>ADD
> > >
> > > There is a typo above s/SET TABLE/SET SCHEMA
> > I will fix this in the next version of the patch.
>
> Modified it.
> I have separated the tests and documentation into a separate patch to
> make review easier. Attached v3 patch with the fixes.
> Thoughts?

The earlier patch does not apply on the head. The v4 patch attached
has the following changes:
a) Rebased it on head. b) Removed pubschemas, pubtables columns and
replaced it with pubtype in pg_publication table. c) List the schemas
in describe publication. d) List the publication in list schemas. e)
Add support for "FOR SCHEMA CURRENT_SCHEMA". f) Tab completion for
"FOR SCHEMA" in create publication and alter publication. g) Included
the newly added structure type to typedefs.lst

Regards,
Vignesh