Re: Internationalized error messages - Mailing list pgsql-hackers

From Andrew Evans
Subject Re: Internationalized error messages
Date
Msg-id 20010309114320.C12977@zembu.com
Whole thread Raw
In response to Re: Internationalized error messages  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Let's say "type mismatch error", code 2200G acc. to SQL.  At one place in
> > the source you write
> > elog(ERROR, "2200G", "type mismatch in CASE expression (%s vs %s)", ...);

Tom Lane <tgl@sss.pgh.pa.us> spake:
> 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...

This is one thing I think VMS does well.  All error messages are a
composite of the subsystem where they originated, the severity of the
error, and the actual error itself.  Internally this is stored in a
32-bit word.  It's been a long time, so I don't recall how many bits
they allocated for each component.  The human-readable representation
looks like "<subsystem>-<severity>-<error>".

--
Andrew Evans


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: porting question: funky uid names?
Next
From: ncm@zembu.com (Nathan Myers)
Date:
Subject: Re: Internationalized error messages