2013/7/19 Dean Rasheed <dean.a.rasheed@gmail.com>:
> On 19 July 2013 04:09, Greg Smith <greg@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 <kaigai@kaigai.gr.jp>