Re: -d option for pg_isready is broken

On Wed, Dec 11, 2013 at 2:29 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Dec 11, 2013 at 2:10 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>>> Well, returning /tmp on Windows is just stupid. I don't see why we
>>>> should feel bad about changing that. A bug is a bug.
>
>>> What I was suggesting was we should take out the pgunixsocket fallback,
>>> not make it even more complicated. That probably implies that we need
>>> still another accessor function to get the socket path.
>
>> Well, I guess. I have a hard time seeing whatever rejiggering we want
>> to do in master as a reason not to back-patch that fix, though.
>
> I guess as long as the pgunixsocket thing is in there, it makes sense
> to substitute DefaultHost for it on Windows, but are we sure that's
> something to back-patch?

Well, it seems like a clear case of returning a ridiculous value, but
I'm willing to be talked out of it if someone can explain how it would
break things. I guess it's possible someone could have code out that
that tests for the exact value /tmp and does something based on that,
but that seems a stretch - and if they did have such code, it would
probably just handle it by substituting localhost anyway.

> Right now, as I was saying, PQhost is in some gray area where it's not too
> clear what its charter is. It's not "what was the host parameter", for
> sure, but we haven't tried to make it an accurate description of the
> connection either. It's a bit less accurate on Windows than elsewhere,
> but do we want to risk breaking anything to only partially resolve that?

I guess it depends on how risky we think it is.

> More generally, if we do go over in 9.4 to the position that PQhost
> reports the host parameter and nothing but, I'm not sure that introducing
> a third behavior into the back branches is something that anybody will
> thank us for.

It doesn't seem very plausible to say that we're just going to
redefine it that way, unless we're planning to bump the soversion.
But maybe we should decide what we *are* going to do in master first,
before deciding what to back-patch.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company