> #define PGERR_TYPE 1854

#define PGSQLSTATE_TYPE	"S0021"    // char(5) SQLSTATE 

The standard calls this error variable SQLSTATE 
(look up in ESQL standard)

first 2 chars are class next 3 are subclass

"00000"  is e.g. Success 
"02000"  is Data not found
"U0xxx" user defined routine error xxx is user defined

> /* somewhere... */
> 
> elogc(ERROR, PGERR_TYPE, "type %s cannot be created because it already exists", ...)

PGELOG(ERROR, PGSQLSTATE_TYPE, ("type %s cannot be created because it already exists", ...))

put varargs into parentheses to avoid need for ... macros see Tom's proposal

I also agree, that we can group different text messages into the same SQLSTATE,
if it seems appropriate for the client to handle them alike.

Andreas

Tue, 20 Mar 2001 17:53:47 +0100
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at>
AW: More on elog and error codes
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at> writes:
> PGELOG(ERROR, PGSQLSTATE_TYPE, ("type %s cannot be created because it already exists", ...))

> put varargs into parentheses to avoid need for ... macros see Tom's proposal

I'd be inclined to make it

PGELOG((ERROR, PGSQLSTATE_TYPE, "type %s cannot be created because it already exists", ...))

The extra parens are ugly and annoying in any case, but they seem
slightly less so if you just double the parens associated with the
PGELOG call.  Takes less thought than adding a paren somewhere in the
middle of the call.  IMHO anyway...

			regards, tom lane

Tue, 20 Mar 2001 12:29:38 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: AW: More on elog and error codes 