Bruce Momjian writes:
> Should we add it for 8.2 and see if we get any problem reports?
No. I don't believe this can work without a far more invasive patch
than this is. To point out just one problem, what of cached plans in
plpgsql functions? Those can't be carried across a genuine connection
To complete the connection pooling for multiple users, it would be great
to have a protocol level option to change roles semi-permanently (to
reduce permissions). RESET SESSION AUTHORIZATION would then bounce back to
that (new, set) role until another protocol-level role "rollback". This
would allo
OK, what would people like done with this patch? Our TODO list has:
* -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 transac
Christopher Kings-Lynne wrote:
What would be absolutely ideal is a reset connection command, plus some
way of knowing via the protocol if it's needed or not.
And a way of notifying the client that a reset has happened.
-O
---(end of broadcast)--
What would be absolutely ideal is a reset connection command, plus some
way of knowing via the protocol if it's needed or not.
Chris
Bruce Momjian wrote:
What did we decide on RESET CONNECTION. Do we want an SQL command or
something only the protocol can do?
-
What did we decide on RESET CONNECTION. Do we want an SQL command or
something only the protocol can do?
---
Oliver Jowett wrote:
> (cc'ing -hackers)
>
> Karel Zak wrote:
>
> > I think command status is common and nice fe
(cc'ing -hackers)
Karel Zak wrote:
I think command status is common and nice feedback for client. I think
it's more simple change something in JDBC than change protocol that is
shared between more tools.
There is a bit of a queue of changes that would be nice to have but
require a protocol version
