PostgreSQL-使用连接提供的变量运行触发器

Question

I need to create an audit table in postgresql, similar to what is described here . However, the actual user making the change is not natively known to PostgreSQL - rather, my application maintains a connection pool (python using psycopg2), and individual users log into the application, not PostgreSQL. How can I let PostgreSQL know what user is making a change from my application? Or do I just need to put all the audit code app side?

Answer 1

I managed to solve this issue using temporary tables. What I ended up doing is the following. Note that this was written using python and psycopg2.

First, I set up my python code to use the with construct to obtain a database cursor from the psycopg2 connection pool. This has the added benefit of automatically returning the connection to the pool, regardless of how the code block exits. I then modified the class used in the with construct to create a temporary table containing whatever data I deem useful, specifically the username, before returning the cursor. This table is created with the ON COMMIT DROP option so I know that when I return the connection to the pool the table will be dropped, preventing any conflict with future usage of the connection.

I then wrote my ON UPDATE trigger to pull the username from this temporary table. Since the trigger fires from within the same transaction as psycopg2 uses to run my SQL statements, it can see the temp table and SELECT the desired username from that. To handle the possibility that the temp table may not exist when the trigger is fired (such as if I make changes directly on the database), I wrapped the SELECT statement in the trigger in an exception handling block. If it gets an error trying to query the temporary table, it falls back to using the value of current_user instead.

Using this setup, I can pass not only the application user name, but any other client/app side information I want, such as client IP address, to the database, thereby enabling me to record values that otherwise wouldn't be accessible to PostgreSQL.