I wrote: > Andrew Dunstan <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers