From: | "Kevin Grittner" <kgrittn(at)mail(dot)com> |
---|---|
To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
Cc: | "Kohei KaiGai" <kaigai(at)kaigai(dot)gr(dot)jp>,"Stephen Frost" <sfrost(at)snowman(dot)net>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"Robert Haas" <robertmhaas(at)gmail(dot)com>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Review of Row Level Security |
Date: | 2012-12-21 16:51:09 |
Message-ID: | 20121221165109.144640@gmx.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs wrote:
> Each table has a single security clause. The clause doesn't enforce
> that it must contain something that depends on role, but that is the
> most easily understood usage of it. We do that to ensure that you can
> embed the intelligence into a function, say hasRowLevelAccess(), which
> doesn't have any provable relationship on role, and maybe wouldn't do
> anything in unit test, yet clearly in production it would do so.
>
> It would be easy enough to include read/write variable clauses by
> using a function similar to TG_OP for triggers, e.g. StatementType.
> That would make the security clause that applied only to reads into
> something like this (StatementType('INSERT, UPDATE') OR other-quals).
In the case where the logic in encapsulated into a function, what
are the logical differences from a BEFORE EACH ROW trigger? If
none, and this is strictly an optimization, what are the benchmarks
showing?
-Kevin
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-12-21 16:53:30 | Re: PL/PgSQL STRICT |
Previous Message | Joel Jacobson | 2012-12-21 16:47:22 | Re: PL/PgSQL STRICT |