> On Dec 6, 2021, at 2:19 AM, Amit Kapila <amit.kapila16@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
propertydoes not exist, and after the patch, it continues to not exist. We could *add* such a property, of course,
thoughthis 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
superuserprivileges 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.
Thispatch intends to correctly handle the situation where a subscription is owned by a non-superuser (task 1, above)
withoutgoing 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