On Wed, Dec 11, 2013 at 8:45 AM, Fujii Masao <masao.fu...@gmail.com> wrote: > On Wed, Dec 11, 2013 at 10:26 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Tue, Dec 10, 2013 at 11:40 PM, Fujii Masao <masao.fu...@gmail.com> wrote: >>> While I was investigaing PQhost() for that approach, I found several >>> problems of PQhost(). >>> >>> (1) PQhost() can return Unix-domain socket directory path even in the >>> platform that >>> doesn't support Unix-domain socket. >>> >>> (2) In the platform that doesn't support Unix-domain socket, when >>> neither host nor hostaddr >>> are specified, the default host 'localhost' is used to connect to >>> the server and >>> PQhost() must return that, but it doesn't. >> >> I think changing PQhost() so that it returns DefaultHost rather than >> conn->pgunixsocket when we don't HAVE_UNIX_SOCKETS is a back-patchable >> bug fix, and I'd say go for it. > > Agreed. > >>> (3) PQhost() cannot return the hostaddr. >> >> However, I'm much less sure whether this is something that we want to >> do at all. It seems like this might be a definition of what the >> function does, and I'm not sure whether the new definition is what >> everyone will want. On the other hand, I'm also not sure that it >> isn't. > > If we don't change PQhost() in that way, we cannot fix the following problem > of wrong output of \conninfo, for example. > > $ psql -d "hostaddr=127.0.0.1" > =# \conninfo > You are connected to database "postgres" as user "postgres" via socket > in "/tmp" at port "5432".
Yeah, that's true. But the whole point of having both host and hostaddr seems to be that you can lie about where you're connecting. If you set host=some.pretty.domain.name hostaddr=1.2.3.4, the point is to say that you're connecting to the first while, under the covers, actually connecting to the second. Now, I am unclear what value this has, but someone at some point evidently thought it was a good idea, so we need to be careful about changing it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers