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

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
Cc: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: PQHost() undefined behavior if connecting string contains both host and hostaddr types
Date: 2018-03-21 13:28:24
Message-ID: 6efa866c-84a1-d83e-db21-5d251303e437@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/21/18 03:40, Michael Paquier wrote:
>>> 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.
> That remark is from me upthread. In the case of a non-established
> connection, I think that we ought to return that.

So, if the connection object is NULL, PQhost() returns NULL. While the
connection is being established (whatever that means), it returns
whatever was specified as host. And when the connection is established,
it returns the host actually connected to. That seems pretty crazy. It
should do only one or the other. Especially since there is, AFAICT, no
way to know at run time whether the value it returned just then is one
or the other.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-03-21 14:00:41 Re: constraint exclusion and nulls in IN (..) clause
Previous Message Peter Eisentraut 2018-03-21 13:20:37 Re: handling of heap rewrites in logical decoding