On Wed, Dec 11, 2013 at 8:45 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Wed, Dec 11, 2013 at 10:26 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Tue, Dec 10, 2013 at 11:40 PM, Fujii Masao <masao.fujii@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