On Wed, Dec 8, 2021 at 11:58 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > But, I think as soon as we are trying to fix (b), we seem to be > allowing non-superusers to apply changes. If we want to do that then > we should be even allowed to change the owners to non-superusers. I > was thinking of the below order: > 1. First fix (c) from the above description "Privileges are only > checked once at the start of a replication connection." > 2A. Allow the transfer of subscriptions to non-superuser owners. This > will be allowed only on disabled subscriptions to make this action > predictable. > 2B. The apply worker should be able to apply the changes provided the > user has appropriate privileges on the objects being accessed by apply > worker. > 3) Allow the creation of subscriptions by non-superusers who are > members of some as yet to be created predefined role, say > "pg_create_subscriptions" > > We all seem to agree that (3) can be done later as an independent > project. 2A, 2B can be developed as separate patches but they need to > be considered together for commit. After 2A, 2B, the first one (1) > won't be required so, in fact, we can just ignore (1) but the only > benefit I see is that if we stuck with some design problem during the > development of 2A, 2B, we would have at least something better than > what we have now. > > You seem to be indicating let's do 2B first as that will anyway be > used later after 2A and 1 won't be required if we do that. I see that > but I personally feel either we should follow 1, 2(A, B) or just do > 2(A, B).
1 and 2B seem to require changing the same code, or related code. 1A seems to require a completely different set of changes. If I'm right about that, it seems like a good reason for doing 1+2B first and leaving 2A for a separate patch. -- Robert Haas EDB: http://www.enterprisedb.com