I know you guys love subject lines like this, but I have a humble request. Would it be possible to have either a GUC setting or a grammar change to allow TEMPORARY tables to be dropped at transaction commit? I know the standard defines the lifetimes of temporary tables to be that of the session. However, I have CORBA middleware which generates a transient session object per client. The object connects to the database at instantiation time and services requests by CORBA's remote method invocation. Often, the methods invoked on the object cause the object to create temporary tables. Each method invocation is a single transaction. But the lifetime of a user's session can be quite long. Worse, CORBA doesn't permit the application to detect when the client "disconnects" - the object (and therefore the database connection) remains unless told explicitly to die. I currently have an evictor pattern remove objects upon which no method invocation has taken place over a given time. But in the meantime, dozens of temporary tables have built up. The idea kind of falls along the same lines as the SET discussion previously. As a test, it took me about 8 lines of code to implement the change. Of course, it was a hack, but it worked nicely.
Would a patch to the grammar be accepted? Along the lines of: CREATE TEMPORARY TABLE ... ON COMMIT DROP; pseudo-compatible with the SQL-standard of: ON COMMIT { DELETE | PRESERVE } ROWS; so one day PostgreSQL's grammar would look like: ... ON COMMIT { DROP | { DELETE | PRESERVE } ROWS }; I suppose I could just change the code to query the catalogue for those temporary tables created during the transaction and issue DROP TABLEs by hand. But I thought it might be an idea of value to others. Mike Mascari [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org