On 13-03-26 12:40 AM, Tom Lane wrote:
Bruce Momjian <br...@momjian.us> writes:
On Mon, Mar 25, 2013 at 07:07:42PM -0400, Tom Lane wrote:
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,

Given all of these poor options, is defining a PQconndefaults() as
perhaps out of memory or a service file problem really not better?

Uh ... no.  In the first place, what evidence have you got that those
are (and will continue to be) the only two possible causes?  In the
second place, this still requires changing every client of
PQconndefaults(), even if it's only to the extent of fixing their
error message texts.  If we're going to do that, I'd rather ask them
to change to a more future-proof solution.

So to summarise:

Plan A: The first patch I attached for pg_upgrade + documentation changes, and changing the other places that call PQconndefaults() to accept failures on either out of memory, or an invalid PGSERVICE

Plan B: Create a new function PQconndefaults2(char * errorBuffer) or something similar that returned error information to the caller.

Plan C: PQconndefaults() just ignores an invalid service but connection attempts fail because other callers of conninfo_add_defaults still pay attention to connection failures. This is the second patch I sent.

Plan D: Service lookup failures are always ignored by conninfo_add_defaults. If you attempt to connect with a bad PGSERVICE set it will behave as if no PGSERVICE value was set. I don't think anyone explicitly proposed this yet.

Plan 'D' is the only option that I'm opposed to, it will effect a lot more applications then ones that call PQconndefaults() and I feel it will confuse users.

I'm not convinced plan B is worth the effort of having to maintain two versions of PQconndefaults() for a while to fix a corner case.

                        regards, tom lane

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to