Re: PQHost() undefined behavior if connecting string contains bothhost and hostaddr types - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: PQHost() undefined behavior if connecting string contains bothhost and hostaddr types
Date
Msg-id a7deeb47-bbb5-bb44-3b87-814bc4463020@2ndquadrant.com
Whole thread Raw
In response to Re: PQHost() undefined behavior if connecting string contains bothhost and hostaddr types  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: PQHost() undefined behavior if connecting string contains bothhost and hostaddr types  (Haribabu Kommi <kommi.haribabu@gmail.com>)
List pgsql-hackers
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.

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.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: configure's checks for --enable-tap-tests are insufficient
Next
From: ilmari@ilmari.org (Dagfinn Ilmari Mannsåker)
Date:
Subject: Re: configure's checks for --enable-tap-tests are insufficient