Re: [HACKERS] gettext calls in pgport

2004-11-01 Thread Bruce Momjian
Andrew Dunstan wrote: 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

Re: [HACKERS] gettext calls in pgport

2004-11-01 Thread Bruce Momjian
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: 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

Re: [HACKERS] gettext calls in pgport

2004-10-24 Thread Bruce Momjian
Peter Eisentraut wrote: Am Montag, 18. Oktober 2004 19:43 schrieb Tom Lane: 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

Re: [HACKERS] gettext calls in pgport

2004-10-19 Thread Peter Eisentraut
Am Montag, 18. Oktober 2004 19:43 schrieb Tom Lane: 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

[HACKERS] gettext calls in pgport

2004-10-18 Thread Peter Eisentraut
As has previously been pointed out, the strings marked up for gettext translation in the pgport library don't work and need to be moved back to where they once came from, unless someone wants to add gettext and locale setup in pgport. (That might be silly, because in theory locale and gettext

Re: [HACKERS] gettext calls in pgport

2004-10-18 Thread Bruce Momjian
Peter Eisentraut wrote: As has previously been pointed out, the strings marked up for gettext translation in the pgport library don't work and need to be moved back to where they once came from, unless someone wants to add gettext and locale setup in pgport. (That might be silly, because

Re: [HACKERS] gettext calls in pgport

2004-10-18 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: Error codes seem like a lot more work than it is worth. I vote for adding gettext support to /port. Also adding error codes duplicates all the error strings in the call sites. Added to open items list: * Add gettext support to src/port He who

Re: [HACKERS] gettext calls in pgport

2004-10-18 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Error codes seem like a lot more work than it is worth. I vote for adding gettext support to /port. Also adding error codes duplicates all the error strings in the call sites. Added to open items list: * Add gettext

Re: [HACKERS] gettext calls in pgport

2004-10-18 Thread Andrew Dunstan
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

Re: [HACKERS] gettext calls in pgport

2004-10-18 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: 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