Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Dec 11, 2013 at 9:35 AM, Andres Freund <andres@2ndquadrant.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.
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.
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.
regards, tom lane