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?)
