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

From vignesh C
Subject Re: Added schema level support for publication.
Date
Msg-id CALDaNm36AHfTV_fV2jKGLWyFbiWURz+s_c9DSDu88JHnGve3Ag@mail.gmail.com
Whole thread Raw
In response to Re: Added schema level support for publication.  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Fri, Aug 6, 2021 at 4:02 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Fri, Aug 6, 2021 at 2:16 PM vignesh C <vignesh21@gmail.com> wrote:
> >
> > On Thu, Aug 5, 2021 at 3:54 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > >
> > > Few more comments:
> > > ===================
> > > 1. Do we need the previous column 'puballtables' after adding pubtype
> > > or pubkind in pg_publication?
> >
> > I felt this should be retained as old client will still be using puballtables, like in case of old client executing
\dRp+ commands.
 
> >
>
> But do we guarantee that old clients work with newer server versions?
> For example, psql docs say: "psql works best with servers of the same
> or an older major version. Backslash commands are particularly likely
> to fail if the server is of a newer version than psql itself." [1]
> (See Notes Section). Similarly, pg_dump docs say: "However, pg_dump
> cannot dump from PostgreSQL servers newer than its own major version;
> it will refuse to even try, rather than risk making an invalid dump."
> [2] (See Notes Section).
>
> It seems Sawada-San has the same question and IIUC docs suggest we
> don't need such compatibility, so what makes you think we need it?

Ok, I was not sure if we can remove any system table columns, hence
had retained it. It seems that my understanding was wrong. I will
remove this column in the next version of the patch.

Regards,
Vignesh



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Use generation context to speed up tuplesorts
Next
From: Ajin Cherian
Date:
Subject: Re: logical replication empty transactions