Bruce Momjian <pgman@candle.pha.pa.us> writes:
> What if we create a 'reset_connection' guc that is initially false, and
> is set to 'true' when someone resets a connection. Then, when it
> happens, the client finds out, reconfigures whatever it needs, then sets
> the value back to 'false'.
It seems to me that one could trivially break any driver that depends on
such a thing, just by issuingSET reset_connection = true;
Then the driver will think the connection has been reset when it has
not, and become completely confused about the actual connection state.
You can't avoid this by making the variable protected, because then the
driver itself would be unable to clear it.
In short I don't think this can work. We'd need an actual protocol
message specifically to report RESET CONNECTION. The loss of backwards
compatibility is not necessarily a bad thing; arguably, you *want*
any client library that doesn't recognize the message to fail, since
otherwise it will be out of sync about the connection state.
Alternatively, depending on what level of client software you think
should be issuing such things, we could make the RESET request be a
new protocol message rather than a SQL statement. Then it couldn't
even be invoked by a non-updated client, and so the compatibility
problem goes away.
regards, tom lane