2013/7/19 Dean Rasheed <dean.a.rash...@gmail.com>: > On 19 July 2013 04:09, Greg Smith <g...@2ndquadrant.com> wrote: >> On 7/18/13 11:03 PM, Stephen Frost wrote: >>> >>> Wasn't there a wiki page about this >>> feature which might also help? Bigger question- is it correct for the >>> latest version of the patch? >> >> >> https://wiki.postgresql.org/wiki/RLS has accumulated a lot of older debris >> that may or may not be useful here. >> >> This useful piece was just presented at PGCon: >> http://www.pgcon.org/2013/schedule/attachments/273_PGcon2013-kaigai-row-level-security.pdf >> That is very up to date intro to the big picture issues. >> > > Hi, > > I took a look at this patch too. I didn't read all the code in detail, > but there was one area I wondered about --- is it still necessary to > add the new field rowsec_relid to RangeTblEntry? > > As far as I can see, it is only used in the new function getrelid() > which replaces the old macro of the same name, so that it can work if > it is passed the index of the sourceRelation subquery RTE instead of > the resultRelation. This seems to be encoding a specific assumption > that a subquery RTE is always going to come from row-level security > expansion. > > Is it the case that this can only happen from expand_targetlist(), in > which case why not pass both source_relation and result_relation to > expand_targetlist(), which I think will make that code neater. As it > stands, what expand_targetlist() sees as result_relation is actually > source_relation, which getrelid() then handles specially. Logically I > think expand_targetlist() should pass the actual result_relation to > getrelid(), opening the target table, and then pass source_relation to > makeVar() when building new TLEs. > > With that change to expand_targetlist(), the change to getrelid() may > be unnecessary, and then also the new rowsec_relid field in > RangeTblEntry may not be needed. > Hmm. I didn't have this idea. It seems to me fair enough and kills necessity to enhance RangeTblEntry and getrelid() indeed. I try to fix up this implementation according to your suggestion.
Thanks, -- KaiGai Kohei <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
