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 17:46:03 |
Message-ID: | 42444E5B.5010300@istreamimaging.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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?)
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Atkins | 2005-03-25 18:00:43 | Re: Persistent data per connection |
Previous Message | Steve Atkins | 2005-03-25 17:41:08 | Re: Persistent data per connection |