From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: gettext calls in pgport |
Date: | 2004-10-18 18:45:43 |
Message-ID: | 41740F57.3060702@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>Somebody just yesterday stuck an
>"fprintf(stderr,...); exit(1)" into one of the pgport routines. This
>sucks, but there is not a lot else that can be done if the code needs
>to exist in both backend and clients. It'd be better to propagate the
>error condition back to the caller.
>
>An alternative possibility is to stop pretending that pgport is agnostic
>about whether it is in backend or frontend. This might mean some
>duplication of code between src/port/ and src/backend/port/, but if
>that's what it takes to have sane error handling, that's what we should do.
>
>
>
>
Maybe you're referring to the patch I sent in to strip the .exe suffix
in get_progname? ;-)
I wondered about that. The choices on strdup() error seemed to be:
. ignore the error and return the unstripped path, knowing the program
would fail in a minute on the next malloc call anyway
. return NULL and patch the code in about 20 places (of which one is the
backend) where get_progname() is called
. print a message and exit
I can see arguments for all of these ;-)
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-10-18 18:55:48 | Re: gettext calls in pgport |
Previous Message | Tom Lane | 2004-10-18 18:34:30 | Re: Final libpq patch? |