On Wed, Mar 20, 2013 at 12:30:32PM -0400, Tom Lane wrote: > Bruce Momjian <br...@momjian.us> writes: > > On Tue, Mar 19, 2013 at 10:12:21AM -0400, Steve Singer wrote: > >>> * Should we document this? > > >> Yes the documentation should indicate that PQconndefaults() can > >> return NULL for more than just memory failures. > > > The attached patch fixes this. I am unclear about backpatching this as > > it hits lot of code, is rare, and adds new translation strings. On the > > other hand, it does crash the applications. > > I don't particularly care for hard-wiring knowledge that bad service > name is the only other reason for PQconndefaults to fail (even assuming > that that's true, a point not in evidence ATM). I care even less for > continuing to use ERRCODE_FDW_OUT_OF_MEMORY for errors clearly outside > its meaning.
Yes, overloading that error code was bad. > I think we should either change PQconndefaults to *not* fail in this > circumstance, or find a way to return an error message. Well, Steve Singer didn't like the idea of ignoring a service lookup failure. What do others think? We can throw a warning, but there is no way to know if the application allows the user to see it. Adding a way to communicate the service failure reason to the user would require a libpq API change, unless we go crazy and say -1 means service failure, and assume -1 can't be a valid pointer. Perhaps we need to remove the memory references and just report a failure, and mention services as a possible cause. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers