Re: Implementing RESET CONNECTION ...
Oliver Jowett <oliver@opencloud.com>
From: Oliver Jowett <oliver@opencloud.com>
To: Karel Zak <zakkr@zf.jcu.cz>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Kris Jurka <books@ejurka.com>, Hans-Jürgen Schönig <postgres@cybertec.at>, eg@cybertec.at, List pgsql-patches <pgsql-patches@postgresql.org>, pgsql-hackers@postgresql.org
Date: 2005-01-04T22:20:36Z
Lists: pgsql-hackers
(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 change. If we're going to change the protocol for any of those we might as well handle RESET CONNECTION cleanly too. > We need some common way how detect on client what's happen on server -- > a way that doesn't mean change protocol always when we add some > feature/command to backend. The command status is possible use for this. Command status only works if commands are directly executed. If you can execute the command indirectly, e.g. via a PL, then you'll miss the notification. Making RESET a top-level-only command isn't unreasonable, but using command status won't work as a general approach for notifying clients. We have a mechanism for GUC changes that uses a separate message (ParameterStatus). Perhaps that should be generalized to report different sorts of connection-related changes. -O