Re: Audit-trail engine: getting the application's layer user_id

* Manuel Sugawara <masm(at)fciencias(dot)unam(dot)mx> [20070425 17:14]:
> > So the view will reference the original table and not the temporary
> > table. Is there a way to achieve this kind of transaction local
> > setting? A transaction based solution would give more security in a
> > situation where a web app server uses a connection pool and you can
> > not guarantee 100% that your reset code is called properly at request
> > init.
>
> Nop, you do the reset part *at the end* of the request cycle:
>
> set session id
> handle request
> reset session id
>
> So, you can guarantee that the id of the session is reset and the
> connection properly disposed to the pool.

If you have full confidence in having control over the request cycle
in your app server, yes.

However, I'm using Ruby on Rails' ActiveRecord and am not 100%
familiar with the way it uses connection pooling and request setup, so
I would feel more safe if I could set something like a temporary table
with ON COMMIT DROP to be sure my app user id will only be visible
from within the transaction that it was set in, and that a value set
can not leak to another web request that reuses the previous db
connection.

Rephrasing the question:

Can I define a view which references a table in a way so that it will
use a temporary table of the same name if it exists, otherwise the
permanent table with that name?

Til