On Thu, Nov 18, 2021 at 9:03 PM Mark Dilger
<mark.dilger@enterprisedb.com> wrote:
>
> > On Nov 18, 2021, at 2:50 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> >> I gave that a slight amount of thought during the design of this patch, but didn't think we could refuse to revoke
superuseron such a basis, and didn't see what we should do with the subscription other than have it continue to be
ownedby the recently-non-superuser. If you have a better idea, we can discuss it, but to some degree I think that is
alsoorthogonal to the purpose of this patch. The only sense in which this patch depends on that issue is that this
patchproposes that non-superuser subscription owners are already an issue, and therefore that this patch isn't creating
anew issue, but rather making more sane something that already can happen.
> >>
> >
> > Don't we want to close this gap irrespective of the other part of the
> > feature? I mean if we take out the part of your 0003 patch that checks
> > whether the current user has permission to perform a particular
> > operation on the target table then the gap related to the owner losing
> > superuser privileges should be addressed.
>
> I don't think there is a gap. The patch does the right thing, causing the subscription whose owner has had superuser
revokedto itself no longer function with superuser privileges. Whether that causes the subscription to fail depends on
whetherthe previously-superuser now non-superuser owner now lacks sufficient privileges on the target relation(s). I
thinkremoving that part of the patch would be a regression.
>
I think we are saying the same thing. I intend to say that your 0003*
patch closes the current gap in the code and we should consider
applying it irrespective of what we do with respect to changing the
... OWNER TO .. behavior. Is there a reason why 0003* patch (or
something on those lines) shouldn't be considered to be applied?
--
With Regards,
Amit Kapila.