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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers