| From: | Adam Rich <adam(dot)r(at)sbcglobal(dot)net> |
|---|---|
| To: | David Kerr <dmk(at)mr-paradox(dot)net> |
| Cc: | postgresql Forums <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Audit Trigger puzzler |
| Date: | 2009-09-03 15:40:53 |
| Message-ID: | 4A9FE385.4000803@sbcglobal.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
David Kerr wrote:
> On Wed, Sep 02, 2009 at 11:44:20PM -0500, Adam Rich wrote:
> - In Oracle, the way we handle audit triggers is by using Package
> - Variables. We emulate some of that functionality in postgresql by
> - adding a custom variable to the configuration file:
> -
> - custom_variable_classes = 'mysess'
> -
> -
> - In your trigger, you could check that this variable was unset, and fall
> - back to the database user.
> -
>
> Thanks! that does seem slick, but will it work with connection pooling?
>
> Dave
>
I don't see why it wouldn't work, as long as you set reset_query_list
properly, and set the session variable the the logged in user whenever
you grab a connection from the pool.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andy Colson | 2009-09-03 15:48:08 | Re: easy task: concurrent select-updates |
| Previous Message | Devrim GÜNDÜZ | 2009-09-03 15:31:48 | Re: PostgreSQL Live CD based on CentOS 5.3 and PG 8.4 released |