Josh Berkus <josh@agliodbs.com> writes:
> Well, the issue with doing this by trigger or RULE is that unlike
> updates and deletes, SELECTS do *not* guarentee single execution. For
> example, if the table is on the loop end of a nested loop, it could be
> fired hundreds or thousands of times. This is the reason why we
> recommend against trying to build a trigger/RULE for SELECT auditing.
There's an even more significant reason why you can't rely on
within-the-database logging if you want to track SELECTs. Imagine
you have a trigger or whatever that tries to log what I do.
I just
begin;
select something-I-shouldn't-know;
rollback;
I just covered all my tracks quite effectively, because the ROLLBACK
canceled any and all side effects of my transaction. But (unlike
if I'd rolled back an update) I still know what I found out.
So, if you want to log accesses to info as opposed to updates, you
really have to use something outside the SQL universe. I concur
with Josh's suggestion to rely on reading the postmaster log.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
