> -----Original Message----- > From: Melvin Davidson [mailto:melvin6925@xxxxxxxxx] > Sent: Tuesday, February 22, 2011 9:43 AM > To: 'Dmitriy Igrishin'; David Johnston > Cc: pgsql-general@xxxxxxxxxxxxxx > Subject: Re: why is there no TRIGGER ON SELECT ? > > Dave and Dmitriy, > > I know a function can be used, but the point is to log a > table whenever "someone else" does a SELECT on it. > > It cannot be depended on that a user will include that (or > any specific function in a SELECT. iow, when any user does > "SELECT ... FROM tablex;" then logging should occur. > > That cannot happen unless there a trigger of the form: > CREATE TRIGGER tg_log_table AFTER SELECT ON tablex FOR EACH > STATEMENT EXECUTE PROCEDURE log_table(); > > And yes, I know access the to table is restricted, but that > is also not the point. Suppose an application requires that a > user/client be charged for each time they access certain data? > > The point, and question is, not how to work around the > problem, but rather, why cannot this functionality be > implemented in triggerts and rules. > > Melvin Davidson > > > Dmitriy > > >Why not use function which returns table and wrap the logging > >(auditing) code in it ? > > Because to use a trigger function, you need a trigger, and as > previously stated, you cannot have a trigger on select. The > same applies for a rule. > > Melvin Davidson > > Somewhat OT (but, m.b. related?): With every view there is: RULE "_RETURN" AS ON SELECT TO <view_name>... DO INSTEAD ... Which PG creates automatically (behind the scene), when view is created. Is there a way, or did anyone try to modify this Rule? It is after all "DO INSTEAD" Rule. Regards, Igor Neyman -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
