On Fri, Jan 12, 2018 at 3:26 PM, Michael Paquier <michael.paqu...@gmail.com> wrote:
> On Fri, Jan 12, 2018 at 11:37:22AM +0900, Michael Paquier wrote: > > I have redone my set of previous tests and can confirm that PQhost is > > behaving as I would expect it should, and those results are the same as > > yours. > > if (conn->connhost != NULL && > - conn->connhost[conn->whichhost].type != CHT_HOST_ADDRESS) > + conn->connhost[conn->whichhost].host != NULL && > + conn->connhost[conn->whichhost].host[0] != '\0') > return conn->connhost[conn->whichhost].host; > - else if (conn->pghost != NULL && conn->pghost[0] != '\0') > - return conn->pghost; > > Upon further review, the second bit of the patch is making me itching. I > think that you should not remove the second check which returns > conn->pghost if a value is found in it. > Thanks for the review. Before posting the patch, first I did the same, upon further study I didn't find any scenario where the value is not present in conn->connhost[conn->whichhost].host and present in conn->pghost. If user provides "host" as connection option, the value is present in both the variables. Even if the connection is unix domain socket, there is a value in conn->connhost[conn->whichhost].host. In case if user provides only hostaddr and host connection option, then in that case, both the members are NULL. So even if we add that case, it will be dead code. I agree with your opinion of creating a new thread of this discussion. Regards, Hari Babu Fujitsu Australia