Tom Lane writes:
> I object to writing "2200G" however, because that has no mnemonic value
> whatever, and is much too easy to get wrong. How about
>
> elog(ERROR, ERR_TYPE_MISMATCH, "type mismatch in argument %d of function %s,
> expected %s, got %s", ...);
>
> where ERR_TYPE_MISMATCH is #defined as "2200G" someplace? Or for that
> matter #defined as "TYPE_MISMATCH"? Content-free numeric codes are no
> fun to use on the client side either...
Well, SQL defines these. Do we want to make our own list? However,
numeric codes also have the advantage that some hierarchy is possible.
E.g., the "22" in "2200G" is actually the category code "data exception".
Personally, I would stick to the SQL codes but make some readable macro
name for backend internal use.
> I am not sure we can/should use gettext (possible license problems?),
Gettext is an open standard, invented at Sun IIRC. There is also an
independent implementation for BSDs in the works. On GNU/Linux system
it's in the C library. I don't see any license problems that way. Is has
been used widely for free software and so far I haven't seen any real
alternative.
> but certainly something like this could be cooked up.
Well, I'm trying to avoid having to do the cooking. ;-)
> Perhaps another way to look at it is that we have a bunch of errors that
> are user-oriented (ie, relate pretty directly to something the user did
> wrong) and another bunch that are system-oriented (relate to internal
> problems, such as consistency check failures or violations of internal
> APIs). We want to provide localized translations of the first set, for
> sure. I don't think we need localized translations of the second set,
> so long as we have some sort of "covering message" that can be localized
> for them.
I'm sure this can be covered in some macro way. A random idea:
elog(ERROR, INTERNAL_ERROR("text"), ...)
expands to
elog(ERROR, gettext("Internal error: %s"), ...)
OTOH, we should not yet make presumptions about what dedicated translators
can be capable of. :-)
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
