-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/14/2015 12:40 PM, Dean Rasheed wrote:
> On 14 July 2015 at 13:59, Robert Haas
> wrote:
>> On Thu, Jul 9, 2015 at 5:47 PM, Joe Conway
>> wrote:
>>> On 06/08/2015 02:08 AM, Dean Rasheed wrote:
Actually I think it is fixable just by allowing
On 14 July 2015 at 13:59, Robert Haas wrote:
> On Thu, Jul 9, 2015 at 5:47 PM, Joe Conway wrote:
>> On 06/08/2015 02:08 AM, Dean Rasheed wrote:
>>> Actually I think it is fixable just by allowing the CURRENT OF
>>> expression to be pushed down into the subquery through the
>>> security barrier vi
On Thu, Jul 9, 2015 at 5:47 PM, Joe Conway wrote:
> On 06/08/2015 02:08 AM, Dean Rasheed wrote:
>> Actually I think it is fixable just by allowing the CURRENT OF
>> expression to be pushed down into the subquery through the
>> security barrier view. The planner is then guaranteed to generate a
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/08/2015 02:08 AM, Dean Rasheed wrote:
> Actually I think it is fixable just by allowing the CURRENT OF
> expression to be pushed down into the subquery through the
> security barrier view. The planner is then guaranteed to generate a
> TID scan,
On 6 June 2015 at 23:28, Peter Geoghegan wrote:
> Attached test case patch shows how RLS fails to play nice with UPDATE
> ... WHERE CURRENT OF.
> [snip]
> What's actually occurring here is that the executor imagines that this
> involves a foreign table scan (although I suppose it's equivocating a
