From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Rahila Syed <rahilasyed90(at)gmail(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, 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-12-10 20:02:08 |
Message-ID: | 202112102002.pejiewltbf3c@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2021-Sep-02, Alvaro Herrera 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. Then it is up to them to figure out what to do.
I thought about this some more and realized that our earlier conclusions
were wrong or at least inconvenient. I think that the best behavior if
you drop a column from a table is to remove the column from the
publication column list, and do nothing else.
Consider the case where you add a table to a publication without a
column filter, and later drop the column. You don't get an error that
the relation is part of a publication; simply, the subscribers of that
publication will no longer receive that column.
Similarly for this case: if you add a table to a publication with a
column list, and later drop a column in that list, then you shouldn't
get an error either. Simply the subscribers of that publication should
receive one column less.
Should be fairly quick to implement ... on it now.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"The problem with the facetime model is not just that it's demoralizing, but
that the people pretending to work interrupt the ones actually working."
(Paul Graham)
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2021-12-10 21:08:24 | Re: Column Filtering in Logical Replication |
Previous Message | Bossart, Nathan | 2021-12-10 19:03:17 | Re: O(n) tasks cause lengthy startups and checkpoints |