Thread: AW: More on elog and error codes

AW: More on elog and error codes

From
Zeugswetter Andreas SB
Date:
> #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


Re: AW: More on elog and error codes

From
Tom Lane
Date:
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