On 12/16/2013 10:43 PM, Tom Lane wrote:
> Craig Ringer <craig@2ndquadrant.com> writes:
>> - Add an attribute to portals that stores the user ID at the time the
>> portal was planned. Possibly extensibly; I'd be surprised if we won't
>> need to associate other local info with a portal later.
>
> This bit seems rather confused. A portal is a runnable query; we
> do not support replanning midstream, and I don't think we support
> changes of UID either.
We _do_ support changes of UID, or rather, current_user returns the
session user ID at the point in time it runs in the portal.
This can be observed with SECURITY DEFINER pl/pgsql functions returning
refcursor, and with cursors that're retained across a SET SESSION
AUTHORIZATION. They don't even need to be WITH HOLD, and s.s.a. can
occur within a transaction.
The point is to return the user ID at the time the portal was created,
rather than whatever the session now is.
-- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
