Re: gettext calls in pgport
От
Tom Lane
Тема
Re: gettext calls in pgport
Дата
Msg-id
27067.1098121390@sss.pgh.pa.us
Ответ на
Re: gettext calls in pgport (Bruce Momjian)
Список
Дерево обсуждения
gettext calls in pgport Peter Eisentraut <peter_e@gmx.net>
Re: gettext calls in pgport Bruce Momjian <pgman@candle.pha.pa.us>
Re: gettext calls in pgport Tom Lane <tgl@sss.pgh.pa.us>
Re: gettext calls in pgport Bruce Momjian <pgman@candle.pha.pa.us>
Re: gettext calls in pgport Peter Eisentraut <peter_e@gmx.net>
Re: gettext calls in pgport Bruce Momjian <pgman@candle.pha.pa.us>
Re: gettext calls in pgport Andrew Dunstan <andrew@dunslane.net>
Re: gettext calls in pgport Bruce Momjian <pgman@candle.pha.pa.us>
Re: gettext calls in pgport Tom Lane <tgl@sss.pgh.pa.us>
Re: gettext calls in pgport Bruce Momjian <pgman@candle.pha.pa.us>
Bruce Momjian 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
В списке pgsql-hackers по дате отправления