Hello Robert,
> I think this patch is a solution in search of a problem.
I take note of this negative opinion.
> [...] It's true that the above example is very confusing, but there's no
> reason for everybody to ever do that.
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.
> Well, no. The fact that a programming language -- or a connection
> string -- can be used to create incomprehensible constructs is an
> artifact of it being powerful and flexible, not a defect.
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.
- \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.
- 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.
> What users should do is just use host. If that causes name lookups
> they want to avoid, they should instead use both host and hostaddr.
THANKS!
This is exactly the simple approach what I'm trying to promote:-) However,
this is NOT what is actually said in the documentation.
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.
> If they do that, they'll be fine.
Sure.
> If they do strange things like specify host and hostaddr strings that
> don't match, then yes, it won't work very well.
Indeed. I think that we should be a bit more user friendly by catching
obvious misconfigurations.
> 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.
--
Fabien.
