Re: Column Filtering in Logical Replication

From: Rahila Syed <rahilasyed90(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Column Filtering in Logical Replication
Date: 2021-09-06 15:55:42
Message-ID: CAH2L28vD7hXMOHNEn2-DShwhP9nL0fdnB-vz4hnT0KL=1ryT0w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Mon, Sep 6, 2021 at 8:53 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:

> On Sat, Sep 4, 2021 at 8:11 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
> wrote:
> >
> > On 2021-Sep-04, Amit Kapila wrote:
> >
> > > On Thu, Sep 2, 2021 at 2:19 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
> wrote:
> > > >
> > > > On 2021-Sep-02, Rahila Syed wrote:
> > > >
> > > > > After thinking about this, I think it is best to remove the entire
> table
> > > > > from publication,
> > > > > if a column specified in the column filter is dropped from the
> table.
> > > >
> > > > Hmm, I think it would be cleanest to give responsibility to the
> user: if
> > > > the column to be dropped is in the filter, then raise an error,
> aborting
> > > > the drop.
> > >
> > > Do you think that will make sense if the user used Cascade (Alter
> > > Table ... Drop Column ... Cascade)?
> >
> > ... ugh. Since CASCADE is already defined to be a potentially-data-loss
> > operation, then that may be acceptable behavior. For sure the default
> > RESTRICT behavior shouldn't do it, though.
> >
>
> That makes sense to me.
>
> However, the default (RESTRICT) behaviour of DROP TABLE allows
removing the table from the publication. I have implemented the removal of
table from publication
on drop column (RESTRICT) on the same lines.

Although it does make sense to not allow dropping tables from publication,
in case of RESTRICT.
It makes me wonder how DROP TABLE (RESTRICT) allows cascading the drop
table to publication.

Did you give any thoughts to my earlier suggestion related to syntax [1]?

> [1] -
> https://www.postgresql.org/message-id/CAA4eK1J9b_0_PMnJ2jq9E55bcbmTKdUmy6jPnkf1Zwy2jxah_g%40mail.gmail.com

For future support to replicate all columns except (x,y,z), I think some
optional keywords like
COLUMNS NOT IN can be inserted between table name and (*columns_list*) as
follows.
ALTER PUBLICATION ADD TABLE tab_name [COLUMNS NOT IN] (x,y,z)
I think this should be possible as a future addition to proposed syntax in
the patch.
Please let me know your opinion.

Thank you,
Rahila Syed

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Laurenz Albe 2021-09-06 16:02:45 Re: Correct handling of blank/commented lines in PSQL interactive-mode history
Previous Message Tom Lane 2021-09-06 15:49:12 Re: Patch: shouldn't timezone(text, timestamp[tz]) be STABLE?