Re: PQHost() undefined behavior if connecting string contains both host and hostaddr types

On Wed, Mar 21, 2018 at 6:06 AM, Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:

> On 3/16/18 00:03, Kyotaro HORIGUCHI wrote:
> > I agree to the conclusion that PQhost() shouldn't return hostaddr
> > "if it has any host name to return". But I still haven't found
> > the reason for returning '/tmp' for IP connection.
> >
> > The attached patch is revised version of that in the following thread.
>
> That patch looks good to me.
>
> Moreover, I wonder whether we shouldn't remove the branch where
> conn->connhost is NULL. When would that be the case? The current
> behavior is to sometimes return the actual host connected to, and
> sometimes the host list. That doesn't make sense.
>

Scenarios where the connection is not yet established, in that scenario
the PQhost() can return the provided connection host information.

Other than the above, it always returns the proper host details.

> I think we should also revert 64f86fb11e20b55fb742af72d55806f8bdd9cd2d,
> in which psql's \conninfo digs out the raw hostaddr value to display,
> which could contain a list of things. I think \conninfo should just
> display the value returned by PQhost(), and if we change PQhost() to
> take hostaddr into account, then this should address the original
> complaint.

As per my understanding of the commit 64f86fb11e20b55fb742af72d55806
f8bdd9cd2d,
the hostaddr is given the preference while displaying instead of host.

Even with the above PQhost() patch, If user provides both host and hostaddr
as options,
the PQhost() function returns host and not the hostaddr. In
commit 7b02ba62, the support
of "Allow multiple hostaddrs to go with multiple hostnames".

If it is fine to display the host in combination of both host and hostaddr,
then it is fine
remove the commit 64f86fb11e20b55fb742af72d55806f8bdd9cd2d.

Regards,
Hari Babu
Fujitsu Australia