> On Nov 19, 2021, at 2:23 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> I was thinking why not separate the ownership and "run as" privileges
> for the subscriptions? We can introduce a new syntax in addition to
> the current syntax for "Owner" for this as:
>
> Create Subscription sub RUNAS <role_name> ...;
> Alter Subscription sub RUNAS <role_name>
>
> Now, RUNAS role will be used to apply changes and perform the initial
> table sync. The owner will be tied to changing some of the other
> properties (enabling, disabling, etc.) of the subscription. Now, we
> still need a superuser to create subscription and change properties
> like CONNECTION for a subscription but we can solve that by having
> roles specific to it as being indicated by Mark in some of his
> previous emails.
I feel disquieted about the "runas" idea. I can't really say why yet. Maybe it is ok, but it feels like a larger
designdecision than just an implementation detail about how subscriptions work. We should consider if we won't soon be
doingthe same thing for other parts of the system. If so, we should choose a solution that makes sense when applied
morebroadly.
Security definer functions could benefit from splitting the owner from the runas role.
Event triggers might benefit from having a runas role. Currently, event triggers are always owned by superusers, but
we'vediscussed allowing non-superuser owners. That proposal still has outstanding issues to be resolved, so I can't be
sureif runas would be helpful, but it might.
Table triggers might benefit from having a runas role. I don't have a proposal here, just an intuition that we should
thinkabout this before designing how "runas" works.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company