Re: gettext calls in pgport

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: gettext calls in pgport
Дата
Msg-id 200410181808.i9II8nL14724@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: gettext calls in pgport  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.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?

And I can update it too.  New text is:
       * fix gettext support to src/port

We need to "fix" it somehow.

> 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.

I have no problem propogating the error condition back to the caller,
but to propogate the error code/reason back means you would need -1 ==
"no file", -2 == "permission violation", etc and you then have those
strings back in the client.  That was Peter's goal, I thought, but it
goes against the idea of centralizing those strings.  I suppose you
could #define all the needed strings in an include file and use those
defines when checking for the error return code, but you have to make
sure you get them all right and adjust for new strings, and it doesn't
seem worth it.

In fact one interesting idea would be to pass a constant error string
back to the caller to fprintf/elog if they want, but that doesn't get
the strings out of /port, and it doesn't allow easy use of passing
fprintf strings with arguments 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.

I tried that but the fix caused more uglyness than it prevented.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: gettext calls in pgport
Следующее
От: Andrew Dunstan
Дата:
Сообщение: confusing log messages on pg_ctl -w start