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

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: PQHost() undefined behavior if connecting string contains bothhost and hostaddr types
Дата
Msg-id a7deeb47-bbb5-bb44-3b87-814bc4463020@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: PQHost() undefined behavior if connecting string contains bothhost and hostaddr types  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Ответы Re: PQHost() undefined behavior if connecting string contains bothhost and hostaddr types  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: configure's checks for --enable-tap-tests are insufficient
Следующее
От: ilmari@ilmari.org (Dagfinn Ilmari Mannsåker)
Дата:
Сообщение: Re: configure's checks for --enable-tap-tests are insufficient