* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> I understand. But doing this right is going to take more than ten lines
> of code, and more than a negligible performance penalty. We have to
> consider whether it's worth it.
It'd be ideal if the performance hit could only be felt by people who
want to enable the option. On the flip side, I don't know that adding a
bit of extra work to SET ROLE would be that bad. If it helps (and I
don't know if it does, I'm still trying to wrap my head around
GetUserIdAndSecContext/SetUserIdAndSecContext), I'd be fine with *not*
trying to log the right role when inside Security Definter functions
(after all, if those are getting called, the user could go look at the
function definition to see which role it's being run as).
I gather one issue is how we can pick up what the correct role name is
when resetting the role due to a failed transaction..? Building a stack
with all the role names pre-cached to deal with that wouldn't be likely
to work and we'd need more than one level to deal with savepoints, I
assume? We could reset it to an Invalid name on abort and then detect
that it needs to be corrected at the start of the next transaction,
perhaps?
Thanks,
Stephen
