|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|Cc:||Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: PQhost may return socket dir for network connection|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, May 1, 2017 at 12:06 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
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.
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?
regards, tom lane
|Next Message||Peter Eisentraut||2017-05-01 17:43:54||Re: Re: logical replication and PANIC during shutdown checkpoint in publisher|
|Previous Message||Pierre Ducroquet||2017-05-01 17:28:59||Re: Bug with pg_basebackup and 'shared' tablespace|