Re: More on elog and error codes - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: More on elog and error codes
Date
Msg-id Pine.LNX.4.30.0103201726200.1639-100000@peter.localdomain
Whole thread Raw
In response to Re: More on elog and error codes  (Philip Warner <pjw@rhyme.com.au>)
Responses Re: More on elog and error codes  (Philip Warner <pjw@rhyme.com.au>)
List pgsql-hackers
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.

Example:

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


In fact, this is my proposal.  The "1854" can be argued, but I like the
rest.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: src/test/regress/README duplicates SGML material
Next
From: Zeugswetter Andreas SB
Date:
Subject: AW: Re: More on elog and error codes