> -----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:
Wecould create an in-transaction SECURITY DEFINER procedure which executes the expression, then drop the procedure
beforecommitting. A built-in feature for doing something like what Heikki suggests could be even more useful.
Cheers,
--Ian
