On 21 December 2012 16:51, Kevin Grittner <kgri...@mail.com> wrote: >> 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?
Logically it is broadly similar to a CHECK constraint, which is also similar to a trigger in a few ways. Implemented as a BEFORE EACH ROW trigger it would need to be a new class of trigger that always executed after all other BEFORE EACH ROW triggers had executed, in the same way that security barrier views act last. The "act last" bit seems to be the most important thing here, just as it was for security barriers and by analogy a string enough reason to add specific syntax to support this case. (Syntax as yet undecided...) > If > none, and this is strictly an optimization, what are the benchmarks > showing? AFAIK its well known that a check constraint is much faster than a trigger. The objection to using triggers is partially for that reason and partially because of the admin overhead, as I already said. Adding a trigger could be done automatically, just as the current patch does with the check constraint approach. So if anyone has benchmarks that show triggers are actually faster, then we could add that automatically instead, I guess. Anyway, hope you can make call on 28th so we can discuss this and agree a way forwards you're happy with. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers