| From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Rahila Syed <rahilasyed90(at)gmail(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-17 07:03:33 |
| Message-ID: | 1f1bee97-4a8e-c5a1-3b96-82d389b34480@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 17.12.21 05:47, Amit Kapila wrote:
> I think in the above sentence, you mean to say "dropped from the
> publication". So, IIUC, you are proposing that if one drops a column
> that was part of the column list of a relation in a publication, an
> error will be raised. Also, if the user specifies CASCADE in Alter
> Table ... Drop Column, then we drop the relation from publication. Is
> that right? BTW, this is somewhat on the lines of what row_filter
> patch is also doing where if the user drops the column that was part
> of row_filter for a relation in publication, we give an error and if
> the user tries to drop the column with CASCADE then the relation is
> removed from the publication.
That looks correct. Consider how triggers behave: Dropping a column
that a trigger uses (either in UPDATE OF or a WHEN condition) errors
with RESTRICT and drops the trigger with CASCADE.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2021-12-17 07:13:51 | Re: Add id's to various elements in protocol.sgml |
| Previous Message | Masahiko Sawada | 2021-12-17 06:46:02 | Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations |