Re: More on elog and error codes

Philip Warner writes:

> If the motivation behind this is to alloy easy translation to SQL error
> codes, then I suggest we have an error definition file with explicit
> translation:
>
> Code SQL Text
> PGERR_TYPALREXI 02xxx "type %s cannot be created because it already exists"
> PGERR_FUNCNOTYPE 02xxx "type %s used as argument %d of function %s doesn't
> exist"
>
> and if we want a generic 'type does not exist', then:
>
> PGERR_NOSUCHTYPE 02xxx "type %s does not exist - %s"
>
> where the %s might contain 'it can't be used as a function argument'.
>
> the we just have
>
> elogc(ERROR, PGERR_TYPALEXI, ...)
>
> /* elsewhere... */
>
> elogc(ERROR, PGERR_FUNCNOTYPE, ...)

This is going to be a disaster for the coder. Every time you look at an
elog you don't know what it does? Is the first arg a %s or a %d? What's
the first %s, what the second? How can this be checked against bugs? (I
know GCC can be pretty helpful here, but does it catch all problems?)

Conversely, when you look at the error message you don't know from what
contexts it's called. The error messages will degrade rapidly in quality
because changing one will become a major project.

> Creating central message files/objects has the added advantage of a much
> simpler locale support - they're just resource files, and they're NOT
> embedded throughout the code.

Actually, the fact that the messages are in the code, where they're used,
and not in a catalog file is a reason why gettext is so popular and
catgets gets laughed at.

--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/