Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229])
	by mail.postgresql.org (Postfix) with ESMTP id A328C1AA5B9B
	for <pgsql-hackers@postgresql.org>;
	Thu, 28 Jun 2012 12:34:27 -0300 (ADT)
Received: from master.phlo.org ([213.47.213.180])
	by magus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <fgp@phlo.org>) id 1SkGjf-0000dQ-Sg
	for pgsql-hackers@postgresql.org; Thu, 28 Jun 2012 15:34:26 +0000
Received: (qmail 19912 invoked by uid 0); 28 Jun 2012 15:34:10 -0000
Received: from chello062178190165.2.15.vie.surfer.at (HELO [192.168.1.48])
	(fgp@[62.178.190.165]) (envelope-sender <fgp@phlo.org>)
	by imap.phlo.org (qmail-ldap-1.03) with AES128-SHA encrypted SMTP
	for <tgl@sss.pgh.pa.us>; 28 Jun 2012 15:34:10 -0000
Subject: Re: [v9.3] Row-Level Security
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=us-ascii
From: Florian Pflug <fgp@phlo.org>
In-Reply-To: <13183.1340897349@sss.pgh.pa.us>
Date: Thu, 28 Jun 2012 17:34:13 +0200
Cc: Kohei KaiGai <kaigai@kaigai.gr.jp>, Robert Haas <robertmhaas@gmail.com>,
	PgHacker <pgsql-hackers@postgresql.org>
Content-Transfer-Encoding: 7bit
Message-Id: <113BF38F-43EC-46D7-93AF-423BEC77B025@phlo.org>
References: 
 <CADyhKSWGtZqpsXtF7_q2FvKRvX6RqW+xv7VmxNmj4gubSBoo-g@mail.gmail.com>
	<CA+Tgmob+P6c1P24u2_STH+2AMbW=q4-X7JqZP+Os43qhiRE4bA@mail.gmail.com>
	<CADyhKSWB3NeSQteujA4aF30qNZZW-fUGcyUJmwiPmG+U2fdUzQ@mail.gmail.com>
	<13017.1340744395@sss.pgh.pa.us>
	<CADyhKSUy8vdfs3UMo10o=FzzgzR6ard=+N4xwCN4xNb3baP1bg@mail.gmail.com>
	<45CAFA51-C0CE-481B-86B9-C383E22AD172@phlo.org>
	<CA+TgmoYMahZ7QijiTHkRuHAsNvovEqwkO3UaksGLhphk-tRX3Q@mail.gmail.com>
	<CADyhKSWLa30t68ic7sJb2DugP6Mptm-bx=NfOPUstORD2KXMGA@mail.gmail.com>
	<DFBBD1D7-68C0-4364-BF02-AFA56BEA8AF6@phlo.org>
	<CADyhKSWTWVmYgW2o8pyTXxC0gUfigXwh+GcmN02U4DrGTfaxRQ@mail.gmail.com>
	<13183.1340897349@sss.pgh.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
X-Mailer: Apple Mail (2.1278)
X-Pg-Spam-Score: -1.9 (-)
X-Archive-Number: 201206/1715
X-Sequence-Number: 210555

On Jun28, 2012, at 17:29 , Tom Lane wrote:
> Kohei KaiGai <kaigai@kaigai.gr.jp> writes:
>> 2012/6/27 Florian Pflug <fgp@phlo.org>:
>>> Hm, what happens if a SECURITY DEFINER functions returns a refcursor?
> 
>> My impression is, here is no matter even if SECURITY DEFINER function
>> returns refcursor.
> 
> I think Florian has a point: it *should* work, but *will* it?
> 
> I believe it works today, because the executor only applies permissions
> checks during query startup.  So those checks are executed while still
> within the SECURITY DEFINER context, and should behave as expected.
> Subsequently, the cursor portal is returned to caller and caller can
> execute it to completion, no problem.

Don't we (sometimes?) defer query startup to the first time FETCH is
called?

best regards,
Florian Pflug