On 12/16/2013 10:43 PM, Tom Lane wrote: > Craig Ringer <cr...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
