From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Mithun Cy
> If you are suggesting me to change in protocol messages, I think that would
> not be backward compatible to older version servers. I also think such level
> of protocol changes will not be allowed. with connection status
> CONNECTION_SETENV used for protocol version 2.0 setup, we sent some query
> like "select pg_catalog.pg_client_encoding()" for same. So I think using
> "SELECT pg_is_in_recovery()" should be fine.
No, there's no concern about compatibility. Please look at this:
https://www.postgresql.org/docs/devel/static/protocol-flow.html#PROTOCOL-ASYNC
[Excerpt]
----------------------------------------
ParameterStatus messages will be generated whenever the active value changes for any of the parameters the backend
believesthe frontend should know about. Most commonly this occurs in response to a SET SQL command executed by the
frontend,and this case is effectively synchronous — but it is also possible for parameter status changes to occur
becausethe administrator changed a configuration file and then sent the SIGHUP signal to the server. Also, if a SET
commandis rolled back, an appropriate ParameterStatus message will be generated to report the current effective value.
At present there is a hard-wired set of parameters for which ParameterStatus will be generated: they are
server_version,server_encoding, client_encoding, application_name, is_superuser, session_authorization, DateStyle,
IntervalStyle,TimeZone, integer_datetimes, and standard_conforming_strings. (server_encoding, TimeZone, and
integer_datetimeswere not reported by releases before 8.0; standard_conforming_strings was not reported by releases
before8.1; IntervalStyle was not reported by releases before 8.4; application_name was not reported by releases before
9.0.)Note that server_version, server_encoding and integer_datetimes are pseudo-parameters that cannot change after
startup.This set might change in the future, or even become configurable. Accordingly, a frontend should simply ignore
ParameterStatusfor parameters that it does not understand or care about.
----------------------------------------
Regards
Takayuki Tsunakawa