Stephen Frost <sfrost@snowman.net> writes:
> Perhaps I was being a bit overzealous in my last response, sorry about
> that. If the point here is that people who are using hostaddr are in an
> environment where DNS is non-functional or actively broken, then yes,
> just bombing out would probably be fine.
Well, if your environment includes broken DNS then you are clearly going
to get nowhere anyway with Kerberos auth, no? The point of hostaddr is
*not* to try to avoid that problem. Rather, it's to allow the
application to shift the time expense of the forward DNS lookup to some
other place than its PQconnect() call. If you've got an app where the
cost of PQconnect() is that critical, you're likely going to want to
avoid Kerberos auth anyway, so I don't think it's all that important
exactly how the two features play together.
As the code stands in HEAD, I think everything is nicely
self-consistent: host is what we believe the server name is for
authentication purposes, and hostaddr is an optional pre-looked-up
address corresponding to that. There is nothing in this suggesting
that we should be expected to try to generate an authentication name
from hostaddr alone. In particular, the fact that Kerberos is capable
of trying to do that is at odds with the other three code paths where
the server name is needed for authentication. I don't feel any need
to expose Kerberos' peculiarity here.
regards, tom lane
