On Tue, Nov 25, 2014 at 09:53:10PM +0900, Fujii Masao wrote:
> On Tue, Nov 25, 2014 at 12:37 PM, Noah Misch <noah@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?
Sure. I'll first issue "git revert 9f80f48", then apply the attached patch.
Since libpq ignores a hostaddr parameter equal to the empty string, this
implementation does likewise. Apart from that, I anticipate behavior
identical to today's code.
