Re: libpq host/hostaddr/conninfo inconsistencies

On Thu, Oct 25, 2018 at 1:06 PM Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
> If you do it, even by accident, there is no way to guess what is wrong
> because the reported informations are inconsistent and does not reflect
> the actual status.

Meh. The reported information is fine. If you tell the system that
foo.com has an IP of 127.0.0.1 when it really doesn't, and then you
get confused because it reports a failure to connect to foo.com when
you really failed to connect to 127.0.0.1, that's a self-inflicted
injury. It's not that I am opposed to helping people avoid
self-inflicted injuries, but this one doesn't seem either likely or
serious.

> I see at least three actual defects:
>
> - \conninfo output does NOT reflect the actual status of a connection
> some cases. I do not see how this can be defended as a powerful
> feature.

Well, again, I think you're talking about the case where host and
hostaddr don't match. But that's not an intended use case, so I'm not
sure it matters. Perhaps extending the \conninfo output with the
actual IP to which somebody connected wouldn't be a bad idea, but in
at least 99% cases, it's just going to be clutter.

> - \connect does NOT work in some trivial cases.
>
> These two above issues are linked to the fact that libpq does not allow to
> know what the actual connection is, so it cannot be described correctly
> nor reused to create another connection.

Yeah, that's not great.

> - the documentation does not say that "host" accepts IPs,
> and implicitely says that hostaddr should be used for IPs.
>
> Once it is clear that "host" accepts IPs, then the host/hostaddr duality
> becomes much less clear, which is the conceptual issue I'm trying to
> solve by improving the documentation.

All I can really say here is that I don't find the current
documentation very confusing, but I agree with you that some people
have been confused by it. I'm not direly opposed to making it more
clear, but I'm not sure that necessitates all of the behavior changes
you are proposing.

I mean, the ssh syntax synopsis says:

ssh [-1246AaCfGgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-E log_file] [-e escape_char]
[-F configfile] [-I pkcs11] [-i identity_file]
[-J [user(at)]host[:port]] [-L address] [-l login_name] [-m mac_spec]
[-O ctl_cmd] [-o option] [-p port] [-Q query_option] [-R address]
[-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]]
[user(at)]hostname [command]

Well, are you confused? That host name could really be an IP address.
But I don't think that's really confusing, because I think it's pretty
widely understood that a hostname is just a proxy for an IP address,
and therefore it's expected that any place where a hostname is
requested, you could instead supply the IP address directly.

What is, arguably, a little confusing in the case of ssh is that
'hostname' could ALSO, instead of being a name that we can find in DNS
or an IP address, correspond to a Host entry in our ~/.ssh/config
file, which could remap the hostname we gave to some other hostname
for DNS lookup purposes, or to an IP address. But we don't have that
problem, because we picked a different keyword for that kind of
functionality -- service=whatever vs. host=whatever.

> The documentation says that host should be used for host names or sockets,
> hostaddr for IP addresses, and then there is a special case when both are
> provided. The implementation does not really do that, as noted above.

You're not the first person to think that -- I believe the pgAdmin 3
developers were confused about the same point -- so it's probably not
as clear as it could be. But I actually do not see that in the
documentation anywhere. It says that the value of hostaddr must be an
IP address, but I do not see that it says that if what you have is an
IP address, you should stuff that in hostaddr rather than host. Maybe
we should explicitly say the opposite e.g.

host Name or IP address of host to connect to.

hostaddr Numeric IP address of host to connect to. Normally not
needed, because PostgreSQL will perform a lookup on the value
specified for host if necessary. If specified, this should be...

> > But the documentation already says that, so I don't really see why we
> > need to change anything here.
>
> It seems that the documentation does not say what you think it says.

Or maybe it doesn't say what YOU think it says. :-)

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