Re: libpq host/hostaddr/conninfo inconsistencies
От | Fabien COELHO |
---|---|
Тема | Re: libpq host/hostaddr/conninfo inconsistencies |
Дата | |
Msg-id | alpine.DEB.2.21.1810251837050.27686@lancre обсуждение исходный текст |
Ответ на | Re: libpq host/hostaddr/conninfo inconsistencies (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: libpq host/hostaddr/conninfo inconsistencies
|
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: