On Tue, Jan 16, 2018 at 05:56:22PM +1100, Haribabu Kommi wrote:
> Without PQhostaddr() function, for the connections where the host is not
> specified, it will be difficult to find out to remote server.
That's true as well, but hostaddr should be used with host only to save
IP lookups... There are recent threads on the matter, like this one:
https://www.postgresql.org/message-id/15728.1493654814%40sss.pgh.pa.us
See particularly the commits cited in this message. PQhostaddr has been
already introduced, and reverted in the tree.
This may lead to some confusion as well. Take for example this
connection string:
'port=6666,5432 hostaddr=127.0.0.1,127.0.0.1 host=/tmp,/tmp'
=# select remote_hostname, remote_hostaddr, remote_port from
pg_stat_wal_receiver;
remote_hostname | remote_hostaddr | remote_port
-----------------+-----------------+-------------
/tmp | 127.0.0.1 | 5432
(1 row)
The documentation states that in this case the IP connection is used,
though this can be confusing for users to show both. I'll bet that we
would get complains about that, without at least proper documentation.
So my take would be to really just use PQhost and PQport, as this does
not remove any usefulness of this feature. If you want to use IP
addresses, there is nothing preventing you to use them in host as well,
and those would show up properly. The commit fest is coming to an end,
so my recommendation would be to move it on the next CF and get feedback
on https://www.postgresql.org/message-id/CAJrrPGdrC4JTJQ4d7PT1Bi7K8nW91XPMPQ5kJ3GWK3ts%2BW-35g%40mail.gmail.com
before concluding on this feature. The problem with PQhost and multiple
hosts is quite different than the 1st thread I am referring in this
email, so let's wait and see for Robert's input.
> With the above two new API's we can display either string or individual
> columns representation of remote server.
I like the naming "remote_*" by the way.
--
Michael