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

On Thu, Mar 22, 2018 at 12:28 AM, Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:

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

OK.

Here I attached the updated patch that returns either the connected
host/hostaddr
or NULL in case if the connection is not established.

I removed the returning default host details, because the default host
details are also available with the connhost member itself.

Regards,
Hari Babu
Fujitsu Australia