RESET CONNECTION behavior

Started by Bruce Momjianalmost 21 years ago2 messageshackers
Jump to latest
#1Bruce Momjian
bruce@momjian.us

Can we get a list features we want for RESET CONNECTION? At this point,
I see ideas but no consistent approach. Some say protocol only, others
say an SQL command is fine, but the protocol has to find out it happened
somehow. Is that a plan?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#2Bruce Momjian
bruce@momjian.us
In reply to: Bruce Momjian (#1)
Re: RESET CONNECTION behavior

Bruce Momjian wrote:

Can we get a list features we want for RESET CONNECTION? At this point,
I see ideas but no consistent approach. Some say protocol only, others
say an SQL command is fine, but the protocol has to find out it happened
somehow. Is that a plan?

I have enhanced our TODO for this item:

* Add RESET CONNECTION command to reset all session state

This would include resetting of all variables (RESET ALL), dropping of
temporary tables, removing any NOTIFYs, cursors, open transactions,
prepared queries, currval()s, etc. This could be used for connection
pooling. We could also change RESET ALL to have this functionality.
The difficult of this features is allowing RESET ALL to not affect
changes made by the interface driver for its internal use. One idea is
for this to be a protocol-only feature. Another approach is to notify
the protocol when a RESET CONNECTION command is used.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073