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 pool....so 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-client-session
state. Presumably you're generating a unique identifier for each client
session somewhere in the client app? You could use that unique identifier
to store whatever information you need for that session in a table.
Yes....but 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
currently "in"? That's the trick. I guess temporary tables are the
answer here (because you can have a unique one per connection)....the
only issue we had was that inside the trigger, if the table didn't
exist, the exception killed the entire function.....have to hit the
pg_classes table I guess to see if temp table exists first (temporary
tables do show up in pg_classes, don't they?)
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
