Re: WIP patch (v2) for updatable security barrier views - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: WIP patch (v2) for updatable security barrier views
Date
Msg-id CA+U5nMKntnJ7xTn4Gz=oQxMPtu3tr=p4TED2_KMTZOLYo3Tpgg@mail.gmail.com
Whole thread Raw
In response to Re: WIP patch (v2) for updatable security barrier views  (Dean Rasheed <dean.a.rasheed@gmail.com>)
List pgsql-hackers
On 29 January 2014 12:20, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:

>> @Dean: If we moved that to rewriter, would expand_security_quals() and
>> preprocess_rowmarks() also move?
>>
>
> Actually I tend to think that expand_security_quals() should remain
> where it is, regardless of where inheritance expansion happens. One of
> the things that simplifies the job that expand_security_quals() has to
> do is that it takes place after preprocess_targetlist(), so the
> targetlist for the security barrier subqueries that it constructs is
> known. Calling expand_security_quals() earlier would require
> additional surgery on preprocess_targetlist() and expand_targetlist(),
> and would probably also mean that the Query would need to record the
> sourceRelation subquery RTE, as discussed upthread.

Looks to me that preprocess_targetlist() could be done earlier also,
if necessary, since it appears to contain checks and additional
columns, not anything related to optimization.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Performance Improvement by reducing WAL for Update Operation
Next
From: Andrew Dunstan
Date:
Subject: jsonb generation functions