> On Dec 6, 2021, at 2:19 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>
>>> If we want to maintain the property that subscriptions can only be
>>> owned by superuser
We don't want to maintain such a property, or at least, that's not what I want.
I don't think that's what Jeff wants, either.
To clarify, I'm not entirely sure how to interpret the verb "maintain" in your
question, since before the patch the property does not exist, and after the
patch, it continues to not exist. We could *add* such a property, of course,
though this patch does not attempt any such thing.
> I understand that but won't that get verified when we look up the
> information in pg_authid as part of superuser() check?
If we added a superuser() check, then yes, but that would take things in a
direction I do not want to go.
As I perceive the roadmap:
1) Fix the current bug wherein subscription changes are applied with superuser
force after the subscription owner has superuser privileges revoked.
2) Allow the transfer of subscriptions to non-superuser owners.
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"
I may be wrong, but it sounds like you interpret the intent of this patch as
enforcing superuserness. That's not so. This patch intends to correctly
handle the situation where a subscription is owned by a non-superuser (task 1,
above) without going so far as creating new paths by which that situation could
arise (tasks 2 and 3, above).
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
