MIME-Version: 1.0
References: <9DFC88D3-1300-4DE8-ACBC-4CEF84399A53@enterprisedb.com>
 <c1c334a2-5d85-687f-f0dc-0ac8c422ca1a@dunslane.net>
 <CD02D159-7260-4247-888F-2CFA7AD3798D@enterprisedb.com>
 <6BB4451E-7B1B-474C-BD1F-DB7531E720C6@enterprisedb.com>
 <aa28945f9f348307c8ac833a937b5fca732668b8.camel@j-davis.com>
 <6A2B0FF6-CC86-48CE-B0D3-5401AA5CFEA9@enterprisedb.com>
 <b6f6ed921b6e219875801857204b14bbc8782e5e.camel@j-davis.com>
 <CF56AC0D-7495-4E8D-A48F-FF38BD8074EB@enterprisedb.com>
In-Reply-To: <CF56AC0D-7495-4E8D-A48F-FF38BD8074EB@enterprisedb.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Thu, 18 Nov 2021 16:20:01 +0530
Message-ID: 
 <CAA4eK1KHE_xmxk==CqTcTzceC_n00tRWBLm3DGUWhaaPTguz3A@mail.gmail.com>
Subject: Re: Non-superuser subscription owners
To: Mark Dilger <mark.dilger@enterprisedb.com>
Cc: Jeff Davis <pgsql@j-davis.com>, Andrew Dunstan <andrew@dunslane.net>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>,
 Robert Haas <robertmhaas@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAA4eK1KHE_xmxk%3D%3DCqTcTzceC_n00tRWBLm3DGUWhaaPTguz3A%40mail.gmail.com>
Precedence: bulk

On Wed, Nov 17, 2021 at 11:56 PM Mark Dilger
<mark.dilger@enterprisedb.com> wrote:
>
> > On Nov 17, 2021, at 9:33 AM, Jeff Davis <pgsql@j-davis.com> wrote:
> >
>
> > This would not address the weirdness of the existing code where a
> > superuser loses their superuser privileges but still owns a
> > subscription. But perhaps we can solve that a different way, like just
> > performing a check when someone loses their superuser privileges that
> > they don't own any subscriptions.
>
> I gave that a slight amount of thought during the design of this patch, b=
ut didn't think we could refuse to revoke superuser on such a basis, and di=
dn't see what we should do with the subscription other than have it continu=
e to be owned by the recently-non-superuser.  If you have a better idea, we=
 can discuss it, but to some degree I think that is also orthogonal to the =
purpose of this patch.  The only sense in which this patch depends on that =
issue is that this patch proposes that non-superuser subscription owners ar=
e already an issue, and therefore that this patch isn't creating a new issu=
e, 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.

--=20
With Regards,
Amit Kapila.