> Some concern was expressed -- not sure exactly where the email is > exactly, and it might've been on pgsql-security -- that doing that > categorically might break things that are currently working. The > people who were concerned included Andres and I forget who else. My > gut reaction was the same as yours, just do it always and don't worry > about it. But if people think that users are likely to run afoul of > the SECURITY_RESTRICTED_OPERATION restrictions in practice, then this > is better, and the implementation complexity isn't high. We could even > think of extending this kind of logic to other places where > SECURITY_RESTRICTED_OPERATION is enforced, if desired.
I personally cannot think of a reasonable example that would be broken, but I agree the code is simple enough. I do think that if there is an actual reason to do this, we'd probably want it in other places where SECURITY_RESTRICTED_OPERATION is enforced too. I think there's some important tests missing related to this: 1. Ensuring that SECURITY_RESTRICTED_OPERATION things are enforced when the user **does not** have SET ROLE permissions to the subscription owner, e.g. don't allow SET ROLE from a trigger. 2. Ensuring that SECURITY_RESTRICTED_OPERATION things are not enforced when the user **does** have SET ROLE permissions to the subscription owner, e.g. allows SET ROLE from trigger. Finally a small typo in the one of the comments: > + * If we created a new GUC nest level, also role back any changes that were s/role/roll/
