Re: gettext calls in pgport

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: gettext calls in pgport
Date: 2004-10-18 17:43:10
Message-ID: 27067.1098121390@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> 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 controls the TODO list dictates the solutions, eh?

I tend to agree with Peter, actually: it would be better to pull error
reporting issues out of pgport. 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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2004-10-18 18:08:49 Re: gettext calls in pgport
Previous Message Tom Lane 2004-10-18 17:31:24 Re: tsearch2 windows make failure