On Wed, Mar 20, 2013 at 12:30:32PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
