Re: Re-enabling SET ROLE in security definer functions

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Exactly.  If that's what you want, we can talk about it, but *SET ROLE
> doesn't solve that problem*.  In fact, a security definer function is a
> lot closer to solving that problem than SET ROLE is.  The premise of SET
> ROLE is that you can always get to any role that the session user could
> get to, so it doesn't "give up permissions" in any non-subvertible
> fashion.

For our purposes, SET ROLE is adequate, because the expression can't contain function calls. But there are alternative: We could create an in-transaction SECURITY DEFINER procedure which executes the expression, then drop the procedure before committing. A built-in feature for doing something like what Heikki suggests could be even more useful.

Cheers,

--Ian