Jeff Amiel wrote:
> (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.
Can't you catch the undefined_table exce
On Fri, Mar 25, 2005 at 12:21:28PM -0600, Jeff Amiel wrote:
> Steve Atkins wrote:
>
> >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
> >t
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
On Fri, Mar 25, 2005 at 11:46:03AM -0600, Jeff Amiel wrote:
> Steve Atkins wrote:
>
> >On Fri, Mar 25, 2005 at 10:56:50AM -0600, Jeff Amiel wrote:
>
> Yesbut inside a trigger function, how do I know which 'row' to look
> at in the table that matches up with the session/connection I am
> curr
Steve Atkins wrote:
On Fri, Mar 25, 2005 at 10:56:50AM -0600, Jeff Amiel wrote:
because the connection is never really dropped...
using a connection poolso it's just reclaimed by the pool on a
connection.close() or after a timeout period
Then you don't really want per-connection stat
On Fri, Mar 25, 2005 at 10:56:50AM -0600, Jeff Amiel wrote:
> because the connection is never really dropped...
> using a connection poolso it's just reclaimed by the pool on a
> connection.close() or after a timeout period
Then you don't really want per-connection state, you want per-clien
> Our latest scheme involves giving each web system user a postgresql user
> account and when we grab a connection from the connection pool, we SET
> SESSION AUTHORIZATION for that user. We can then access the user info
> from the trigger.
>
> But is there a better/different way to persist da
because the connection is never really dropped...
using a connection poolso it's just reclaimed by the pool on a
connection.close() or after a timeout period
Tom Lane wrote:
Jeff Amiel <[EMAIL PROTECTED]> writes:
We've been struggling for several days now to come up with a mechanism
tha
Jeff Amiel <[EMAIL PROTECTED]> writes:
> We've been struggling for several days now to come up with a mechanism
> that allows us to establish a mechanism to store data that remains
> persistent for the life of the connection.
Why don't you just store it in a temporary table? Goes away at
connec
We've been struggling for several days now to come up with a mechanism
that allows us to establish a mechanism to store data that remains
persistent for the life of the connection.
Essentially we have a web based application that utilizes a connection
pool (using one single 'super' postgresql d
10 matches
Mail list logo
