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

From Peter Eisentraut
Subject Re: Skipping schema changes in publication
Date
Msg-id 4f4867da-f581-0330-974f-da9031ac3e1c@enterprisedb.com
Whole thread Raw
In response to Re: Skipping schema changes in publication  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: Skipping schema changes in publication  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On 14.04.22 15:47, Peter Eisentraut wrote:
> 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.

Another problem in general with this "all except these" way of 
specifying things is that you need to track negative dependencies.

For example, assume you can't add a table to a publication unless it has 
a replica identity.  Now, if you have a publication p1 that says 
includes "all tables except t1", you now have to check p1 whenever a new 
table is created, even though the new table has no direct dependency 
link with p1.  So in more general cases, you would have to check all 
existing objects to see whether their specification is in conflict with 
the new object being created.

Now publications don't actually work that way, so it's not a real 
problem right now, but similar things could work like that.  So I think 
it's worth thinking this through a bit.




pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Add pg_strtoupper and pg_strtolower functions
Next
From: Peter Eisentraut
Date:
Subject: Re: Add a new function and a document page to get/show all the server hooks