At Mon, 1 May 2017 15:48:17 -0400, Robert Haas <robertmh...@gmail.com> wrote in <ca+tgmozcygsb621i35ac9tjar__f9fqbmrphfcone4ane22...@mail.gmail.com> > On Mon, May 1, 2017 at 1:36 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Robert Haas <robertmh...@gmail.com> writes: > >> On Mon, May 1, 2017 at 12:06 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >>> Having said that, the behavior stated in $subject does sound wrong. > > > >> I'm not sure. My understanding of the relationship between host and > >> hostaddr is that hostaddr overrides our notion of where to find host, > >> but not our notion of the host to which we're connecting. Under that > >> definition, the current behavior as described by Kyotaro sounds > >> correct. > > > > Perhaps. But hostaddr also forces us to believe that we're making an > > IP connection, so it still seems pretty dubious to return a socket > > path. The true situation is that we're connecting to an IP host that > > we do not know the name of. > > Yes, I think that's a reasonable interpretation. > > > I notice that one of the recent changes was made to avoid situations where > > PQhost() would return NULL and thereby provoke a crash if the application > > wasn't expecting that (which is not unreasonable of it, since the PQhost() > > documentation mentions no such hazard). So I would not want to see us > > return NULL in this case. > > And I believe we already considered and rejected the idea of having it > > return the hostaddr string, back in some of the older discussions. > > (We could revisit that decision, no doubt, but let's go back and see > > what the reasoning was first.) > > > > But maybe returning an empty string ("") would be OK? > > Yeah, that might be OK. But I'd be inclined not to back-patch any > behavior changes we make in this area unless it's clear that 9.6 > regressed relative to previous releases.
I personally don't have a specific wish on this since I don't have a specific usage of PQhost. (I think that users are reposible for the result of contradicting host and hostaddr.) However, it might be a problem that the documentation doesn't mention what the returned value from PQhost is. https://www.postgresql.org/docs/9.6/static/libpq-status.html > Returns the server host name of the connection. This can be a > host name, an IP address, or a directory path if the connection > is via Unix socket. (The path case can be distinguished because > it will always be an absolute path, beginning with /.) I don't think more strict definition is required but the above should describe the expected usage or obvious limitation. Anyway it is contradicting to the current behavior. It can return a socket path for a IP connection. regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers