Re: -d option for pg_isready is broken

On Wed, Dec 11, 2013 at 11:24 AM, 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 9:35 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>>> One use case is accessing a particular host when using DNS round robin
>>> to standbys in combination with SSL.
>
>> Ah, interesting point. And it's not inconceivable that some
>> application out there could be using PQhost() to retrieve the host
>> from an existing connection object and reusing that value for a new
>> connection, in which case redefining it to sometimes return hostaddr
>> would break things. So I think we shouldn't do that.
>
> I think the only reasonable way to fix this is to improve the logic
> in psql, not turn PQhost() into a mess with no understandable definition.
> If that means we need to add a separate PQhostaddr() query function,
> so be it. We won't be able to fix the complained-of bug in back branches,
> but I'd rather live with that (it's basically just cosmetic anyway)
> than risk introducing perhaps-not-so-cosmetic bugs into other existing
> applications.

I can't argue with that.

> In general, I think the definition of these query functions ought to
> be "what was the value of this parameter when the connection was made".
> As such, I'm not even sure that the pgunixsocket behavior that's in
> PQhost now is a good idea, much less that we should extend that hack
> to cover DefaultHost.

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.

> There is room also for a function defined as "give me a textual
> description of what I'm connected to", which is not meant to reflect any
> single connection parameter but rather the total behavior. Right now
> I think PQhost is on the borderline of doing this instead of just
> reporting the "host" parameter, but I think rather than pushing it
> across that border we'd be better off to invent a function explicitly
> charged with doing that. That would give us room to do something
> actually meaningful with host+hostaddr cases, for instance. I think
> really what ought to be printed in such cases is something like
> "host-name (address IP-address)"; leaving out the former would be
> unhelpful but leaving out the latter is outright misleading.
>
> On the other hand, I'm not sure how much of a translatability problem
> it'd be to wedge such a description into a larger message. Might be
> better to just put the logic into psql.

libpq needs to expose enough functionality to make this simple for
psql, but psql should be the final arbiter of the output format.

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