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? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
