On Tue, Jan 16, 2018 at 5:56 PM, Haribabu Kommi <kommi.harib...@gmail.com> wrote:
> > On Tue, Jan 16, 2018 at 2:55 PM, Michael Paquier < > michael.paqu...@gmail.com> wrote: > >> >> Note that I still find this API confusing, it seems to me that just >> sorting out the confusion problems with PQhost and then use it would be >> more simple. >> > > OK, Understood. Even if the confusion problems with PQhost that are > discussed in [1] are solved, we need two new API's that are required to\ > display the proper remote server details. > > PQhostNoDefault - Similar like PQhost but doesn't return default host > details. > > Displaying default value always some confuse even if the user doesn't > provide > the host details, so to avoid that confusion, we need this function. > > PQhostaddr - Return hostaddr used in the connection. > > Without PQhostaddr() function, for the connections where the host is not > specified, it will be difficult to find out to remote server. > > With the above two new API's we can display either string or individual > columns > representation of remote server. > As I didn't hear objections, I changed the patch as per the above description with two new libpq API's and also with three additional columns "remote_hostname", "remote_hostaddr" and "remote_port" to the pg_stat_wal_receiver view. I didn't explicitly add the CONNECTION_BAD, because the added libpq functions must return the value even the connection is not established. Updated patch attached. Regards, Hari Babu Fujitsu Australia
0002-pg_stat_wal_receiver-to-display-connected-host.patch
Description: Binary data
0001-Addition-of-two-new-libpq-API-s.patch
Description: Binary data
