On Wed, Dec 8, 2021 at 11:58 PM Amit Kapila <amit.kapila16@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