I wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Looks like it was. Good catch. What's the best way to fix?
> So far as I can see, none of the spec-defined EAI_XXX codes map very
> nicely to "path name too long". Possibly we could return EAI_SYSTEM
> and set errno to ENAMETOOLONG, but I'm not sure the latter is very
> portable either.
I tried this out and found that at least on Linux, gai_strerror() is too
stupid to pay attention to errno anyway; you just get "System error",
which is about as unhelpful as it could possibly be. I don't see any
way that we can get a more specific error message to be printed without
eliminating use of gai_strerror and providing our own infrastructure for
reporting getaddrinfo errors. While that wouldn't be incredibly awful
(we have such infrastructure already for ancient platforms...), it
still kinda sucks.
> Another line of attack is to just teach getaddrinfo_unix() to malloc its
> result struct big enough to hold whatever the supplied path is.
I tried this out too, and found that it doesn't work well, because both
libpq and the backend expect to be able to copy getaddrinfo results into
fixed-size SockAddr structs. We could probably fix that by adding
another layer of pointers and malloc operations, but it would be
somewhat invasive. Given the lack of prior complaints it's not clear
to me that it's worth that much trouble --- although getting rid of our
hard-wired assumptions about the maximum result size from getaddrinfo is
attractive from a robustness standpoint.
I'm a bit tempted to just replace EAI_FAIL with EAI_MEMORY here, so
that you'd get messages similar to "Memory allocation failure". That
might at least point your thoughts in the right direction, whereas
"Non-recoverable failure in name resolution" certainly conveys nothing
of use.
Thoughts?
regards, tom lane
