Re: PQhost may return socket dir for network connection

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: robertmhaas(at)gmail(dot)com
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PQhost may return socket dir for network connection
Date: 2017-05-10 06:34:03
Message-ID: 20170510.153403.28896042.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Mon, 1 May 2017 15:48:17 -0400, Robert Haas <robertmhaas(at)gmail(dot)com> wrote in <CA+TgmoZcyGsb621i35AC9TJar__F9fQbmRPHfCOnE4aNE227HA(at)mail(dot)gmail(dot)com>
> On Mon, May 1, 2017 at 1:36 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > 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
> >> 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2017-05-10 07:56:58 Re: idea: custom log_line_prefix components besides application_name
Previous Message Noah Misch 2017-05-10 06:04:55 Re: Time based lag tracking for logical replication