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
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 |