From: | Jeff Amiel <jamiel(at)istreamimaging(dot)com> |
---|---|
To: | Steve Atkins <steve(at)blighty(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Persistent data per connection |
Date: | 2005-03-25 18:21:28 |
Message-ID: | 424456A8.7070404@istreamimaging.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Steve Atkins wrote:
>Using a temporary table to store that unique token is how I'd do it.
>
>Rather than grovel through the system tables during the trigger I'd do
>all the work at the client session setup. As the first thing, write
>the token into the temporary table. If that fails, create the
>temporary table and retry. Then create the transaction you want to use
>for all the other operations in the session.
>
>
>
Our problem is that we have batch/standalone applications that will not
be using the connection pool (as well as developers that may directly
modify production tables in rare instances). In those cases (heck, all
cases) , the audit triggers themselves (when an update/insert/delete
takes place) have to look to see if a temp table exists to pull the
user data from. It wont exist in tese cases, but the triggers dont know
this.....
From | Date | Subject | |
---|---|---|---|
Next Message | Patrick TJ McPhee | 2005-03-25 18:32:27 | Re: psql variables |
Previous Message | Steve Atkins | 2005-03-25 18:00:43 | Re: Persistent data per connection |