Re: pg_upgrade segfaults when given an invalid PGSERVICE value - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_upgrade segfaults when given an invalid PGSERVICE value
Date
Msg-id 29408.1364272825@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_upgrade segfaults when given an invalid PGSERVICE value  (Bruce Momjian <bruce@momjian.us>)
Responses Re: pg_upgrade segfaults when given an invalid PGSERVICE value  (Steve Singer <ssinger@ca.afilias.info>)
List pgsql-hackers
Bruce Momjian <bruce@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,
>> period.

> 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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL)
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL)