On 29 January 2014 12:20, Dean Rasheed <dean.a.rash...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
