On Mon, Mar 25, 2013 at 07:07:42PM -0400, Tom Lane wrote: > Bruce Momjian <br...@momjian.us> writes: > > We are taking this approach because PQconndefaults() doesn't have an API > > to return the error cause, while other API calls do. Returning true so > > we can later report the right error from a later API call just feels > > wrong. > > Well, plan B would be to invent a replacement function that does have > the ability to return an error message, but that seems like a lot of > work for a problem that's so marginal that it wasn't noticed till now. > (It's not so much creating the function that worries me, it's fixing > clients to use it.) > > Plan C would be to redefine bogus value of PGSERVICE as not an error, > period.
Given all of these poor options, is defining a PQconndefaults() as perhaps out of memory or a service file problem really not better? -- 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
