Re: [v9.4] row level security - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [v9.4] row level security
Date
Msg-id 14602.1374246003@sss.pgh.pa.us
Whole thread Raw
In response to Re: [v9.4] row level security  (Dean Rasheed <dean.a.rasheed@gmail.com>)
List pgsql-hackers
Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> 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.

I haven't read the patch at all, but I would opine that anything that's
changing the behavior of getrelid() is broken by definition.  Something
is being done at the wrong level of abstraction if you think that you
need to do that.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: LATERAL quals revisited
Next
From: Andrew Dunstan
Date:
Subject: Re: confusing typedefs in jsonfuncs.c