Re: [HACKERS] PQhost may return socket dir for network connection - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] PQhost may return socket dir for network connection
Date
Msg-id 19297.1493660213@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] PQhost may return socket dir for network connection  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] PQhost may return socket dir for network connection  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, May 1, 2017 at 12:06 PM, Tom Lane <tgl@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.

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



pgsql-hackers by date:

Previous
From: Pierre Ducroquet
Date:
Subject: Re: [HACKERS] Bug with pg_basebackup and 'shared' tablespace
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] Re: logical replication and PANIC during shutdowncheckpoint in publisher