User-Id Tracking when Portal was started

The attached patch is delivered from the discussion around row-level
access control feature. A problem Florian pointed out is refcursor
declared in security definer function. Even though all the permission
checks are applied based on privilege of the owner of security-definer
function in case when it tries to define a cursor bound to a particular
query, it shall be executed under the credential of executor.
In the result, "current_user" or "has_table_privilege()" will return
unexpected result, even if it would be used in as a part of security
policy for each row.

This patch enables to switch user-id when user tried to execute
a portal being started under the different user's credential.

postgres=# CREATE FUNCTION f1(refcursor) RETURNS refcursor
postgres-#     SECURITY DEFINER LANGUAGE plpgsql
postgres-#     AS 'BEGIN OPEN $1 FOR SELECT current_user,* FROM t1;
postgres'#         RETURN $1; END';
CREATE FUNCTION

postgres=# SET SESSION AUTHORIZATION alice;
SET
postgres=> BEGIN;
BEGIN
postgres=> SELECT f1('abc');
 f1
-----
 abc
(1 row)

postgres=> FETCH abc;
 current_user | a |  b
--------------+---+-----
 kaigai       | 1 | aaa          <=== 'abc' was started under the
kaigai's privilege
(1 row)

postgres=> SELECT current_user;
 current_user
--------------
 alice
(1 row)

postgres=> DECLARE xyz CURSOR FOR SELECT current_user, * FROM t1;
DECLARE CURSOR
postgres=> FETCH xyz;
 current_user | a |  b
--------------+---+-----
 alice        | 1 | aaa
(1 row)

postgres=> RESET SESSION AUTHORIZATION;
RESET
postgres=# FETCH xyz;          <=== 'xyz' was started under the
kaigai's privilege
 current_user | a |  b
--------------+---+-----
 alice        | 2 | bbb
(1 row)


BTW, same problem will be caused in case when security label of
the client would be switched. Probably, a hook should be injected
around the places where I patched with this patch.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>