Cleanup of rewriter and planner handling of Query.hasRowSecurity flag. Be sure to pull up the subquery's hasRowSecurity flag when flattening a subquery in pull_up_simple_subquery(). This isn't a bug today because we don't look at the hasRowSecurity flag during planning, but it could easily be a bug tomorrow.
Likewise, make rewriteRuleAction() pull up the hasRowSecurity flag when absorbing RTEs from a rule action. This isn't a bug either, for the opposite reason: the flag should never be set yet. But again, it seems like good future proofing. Add a comment explaining why rewriteTargetView() should *not* set hasRowSecurity when adding stuff to securityQuals. Improve some nearby comments about securityQuals processing, and document that field more completely in parsenodes.h. Patch by me, analysis by Dean Rasheed. Discussion: <CAEZATCXZ8tb2DV6f=bkhsmv6u_grcz0czbw2j-qu84rxsuk...@mail.gmail.com> Branch ------ master Details ------- http://git.postgresql.org/pg/commitdiff/24aef33804be5d7d71bc3932ced3407fce71e354 Modified Files -------------- src/backend/optimizer/prep/prepjointree.c | 3 +++ src/backend/rewrite/rewriteHandler.c | 32 ++++++++++++++++++++++++------- src/include/nodes/parsenodes.h | 9 ++++++++- 3 files changed, 36 insertions(+), 8 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
