Re: Skipping schema changes in publication - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Skipping schema changes in publication
Date
Msg-id a2004f08-eb2f-b124-115c-f8f18667e585@enterprisedb.com
Whole thread Raw
In response to Re: Skipping schema changes in publication  (vignesh C <vignesh21@gmail.com>)
Responses Re: Skipping schema changes in publication  ("Euler Taveira" <euler@eulerto.com>)
Re: Skipping schema changes in publication  (vignesh C <vignesh21@gmail.com>)
Re: Skipping schema changes in publication  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
On 12.04.22 08:23, vignesh C wrote:
> I have also included the implementation for skipping a few tables from
> all tables publication, the 0002 patch has the implementation for the
> same.
> This feature is helpful for use cases where the user wants to
> subscribe to all the changes except for the changes present in a few
> tables.
> Ex:
> CREATE PUBLICATION pub1 FOR ALL TABLES SKIP TABLE t1,t2;
> OR
> ALTER PUBLICATION pub1 ADD SKIP  TABLE t1,t2;

We have already allocated the "skip" terminology for skipping 
transactions, which is a dynamic run-time action.  We are also using the 
term "skip" elsewhere to skip locked rows, which is similarly a run-time 
action.  I think it would be confusing to use the term SKIP for DDL 
construction.

Let's find another term like "omit", "except", etc.

I would also think about this in broader terms.  For example, sometimes 
people want features like "all columns except these" in certain places. 
The syntax for those things should be similar.

That said, I'm not sure this feature is worth the trouble.  If this is 
useful, what about "whole database except these schemas"?  What about 
"create this database from this template except these schemas".  This 
could get out of hand.  I think we should encourage users to group their 
object the way they want and not offer these complicated negative 
selection mechanisms.



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: BufferAlloc: don't take two simultaneous locks
Next
From: Robert Haas
Date:
Subject: Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)