| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
| Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Karol Trzcionka <karlikt(at)gmail(dot)com>, Mike Blackwell <mike(dot)blackwell(at)rrd(dot)com>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [v9.4] row level security |
| Date: | 2013-07-19 15:00:03 |
| Message-ID: | 14602.1374246003@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2013-07-19 15:06:49 | Re: confusing typedefs in jsonfuncs.c |
| Previous Message | Tom Lane | 2013-07-19 14:57:19 | Re: LATERAL quals revisited |