On Tue, Nov 25, 2014 at 12:37 PM, Noah Misch <n...@leadboat.com> wrote: > On Wed, Jan 22, 2014 at 11:48:26PM +0900, Fujii Masao wrote: >> (3) PQhost() cannot return the hostaddr. > >> We can fix the problem (3) by changing PQhost() so that it also >> returns the hostaddr. But this change might break the existing >> application using PQhost(). So, I added new libpq function PQhostaddr() >> which returns the hostaddr, and changed \conninfo so that it reports >> correct connection information by using both PQhost() and PQhostaddr(). > >> + <varlistentry id="libpq-pqhostaddr"> >> + <term> >> + <function>PQhostaddr</function> >> + <indexterm> >> + <primary>PQhostaddr</primary> >> + </indexterm> >> + </term> >> + >> + <listitem> >> + <para> >> + Returns the server numeric IP address or host name of the >> connection. >> + <synopsis> >> + char *PQhostaddr(const PGconn *conn); >> + </synopsis> >> + </para> >> + </listitem> >> + </varlistentry> > > From reading this documentation, I assumed this function would return a > non-empty value for every TCP connection. After all, every TCP connection has > a peer IP address. In fact, PQhostaddr() returns the raw value of the > "hostaddr" connection parameter, whether from a libpq function argument or > from the PGHOSTADDR environment variable. (If the parameter and environment > variable are absent, it returns NULL. Adding "hostaddr=" to the connection > string makes it return the empty string.) A caller wanting the specific raw > value of a parameter could already use PQconninfo(). I suspect this new > function will confuse more than help. What do you think of reverting it and > having \conninfo use PQconninfo() to discover any "hostaddr" value?
Sounds reasonable to me. Are you planning to implement and commit the patch? Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
