Re: Skipping schema changes in publication

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: vignesh C <vignesh21(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Skipping schema changes in publication
Date: 2022-05-04 13:34:54
Message-ID: 4f4867da-f581-0330-974f-da9031ac3e1c@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2022-05-04 13:39:34 Re: Add a new function and a document page to get/show all the server hooks
Previous Message Alvaro Herrera 2022-05-04 13:13:31 Re: Add pg_strtoupper and pg_strtolower functions