Re: More on elog and error codes

At 17:35 20/03/01 +0100, Peter Eisentraut wrote:
>Philip Warner writes:
>
>>     elog(CACHELOOKUPFAIL, cacheItemThatFailed);
>
>The disadvantage of this approach, which I tried to explain in a previous
>message, is that we might want to have different wordings for different
>occurences of the same class of error.
>
>Additionally, the whole idea behind having error *codes* is that the
>client program can easily distinguish errors that it can handle specially.
>Thus the codes should be numeric or some other short, fixed scheme.  In
>the backend they could be replaced by macros.

This seems to be just an argument for constructing the value of
PGERR_CACHELOOKUPFAIL carefully (which is what the VMS message source files
did). The point is that when they are used by a developer, they are simple.



>#define PGERR_TYPE 1854
>
>/* somewhere... */
>
>elogc(ERROR, PGERR_TYPE, "type %s cannot be created because it already
exists", ...)
>
>/* elsewhere... */
>
>elogc(ERROR, PGERR_TYPE, "type %s used as argument %d of function %s
doesn't exist", ...)
>

I can appreciate that there may be cases where the same message is reused,
but that is where parameter substitution comes in. 

In the specific example above, returning the same error code is not going
to help the client. What if they want to handle "type %s used as argument
%d of function %s doesn't exist" by creating the type, and silently ignore
"type %s cannot be created because it already exists"?

How do you handle "type %s can not be used as a function return type"? Is
this PGERR_FUNC or PGERR_TYPE?

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


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.

Finally, if you do want to have some kind of error classification beyond
the SQL code, it could be encoded in the error message file.


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/