On Thu, Nov 24, 2011 at 04:28, Theo Schlossnagle <je...@omniti.com> wrote:
> So... here's my first whack at solving this with some flexibility.
>
> The first thing I did was add hook points where immediate statement
> logging happens "pre_exec" and those that present duration
> "post_exec". These should, with optimization turned on, have only a
> few instructions of impact when no hooks are registered (we could
> hoist the branch outside the function call if that were identified as
> an issue).
Note that the hook mechanism you've built is a departure from how
other hooks are managed in Postgres. Traditionally hooks are just
global function pointers, and each consumer is responsible for storing
the previous value of the hook and chain-calling it in the handler. If
you want to change this pattern, I think you should start another
discussion.
E.g. hook registration looks like:
next_object_access_hook = object_access_hook;
object_access_hook = sepgsql_object_access;
static void
sepgsql_object_access(ObjectAccessType access, Oid classId, Oid
objectId, int subId)
{
if (next_object_access_hook)
(*next_object_access_hook) (access, classId, objectId, subId);
Regards,
Marti
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
