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:

Reply via email to