On Thu, May 5, 2022 at 9:20 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Wed, May 4, 2022 at 7:05 PM Peter Eisentraut > <peter.eisentr...@enterprisedb.com> wrote: > > > > 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. > > > > Yes, I think we should avoid adding such negative dependencies. We > have carefully avoided such dependencies during row filter, column > list work where we don't try to perform DDL time verification. > However, it is not clear to me how this proposal is related to this > example or in general about tracking negative dependencies? >
I mean to say that even if we have such a restriction, it would apply to "for all tables" or other publications as well. In your example, consider one wants to Alter a table and remove its replica identity, we have to check whether the table is part of any publication similar to what we are doing for relation persistence in ATPrepChangePersistence. > AFAIR, we > currently have such a check while changing persistence of logged table > (logged to unlogged, see ATPrepChangePersistence) where we cannot > allow changing persistence if that relation is part of some > publication. But as per my understanding, this feature shouldn't add > any such new dependencies. I agree that we have to ensure that > existing checks shouldn't break due to this feature. > > > 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. > > > > This is a good point and I agree that we should be careful to not add > some new negative dependencies unless it is really required but I > can't see how this proposal will make it more prone to such checks. > -- With Regards, Amit Kapila.
