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