Re: error codes

From: "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Neil Conway" <nconway(at)klamath(dot)dyndns(dot)org>
Cc: "PostgreSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: error codes
Date: 2002-07-18 08:01:20
Message-ID: 46C15C39FEB2C44BA555E356FBCD6FA4961E24@m0114.s-mxs.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Bruce wrote:
> Actual error code numbers/letters. I think the new elog levels will
> help with this. We have to decide if we want error numbers, or some
> pneumonic like NOATTR or CONSTVIOL. I suggest the latter.

Since there is an actual standard for error codes, I would strongly suggest
to adhere. The standardized codes are SQLSTATE a char(5) (well standardized
for many classes of db errors). Also common, but not so standardized is SQLCODE
a long (only a very few are standardized, like 100 = 'no data found').
And also sqlca. Also look at ecpg for sqlcode and sqlca.

A Quote from dec rdb:
--------------------------------------------------------------------
o SQLCODE-This is the original SQL error handling mechanism.
It is an integer value. SQLCODE differentiates among errors
(negative numbers), warnings (positive numbers), succesful
completion (0), and a special code of 100, which means no
data. SQLCODE is a deprecated feature of the ANSI/ISO SQL
standard.

o SQLCA-This is an extension of the SQLCODE error handling
mechanism. It contains other context information that
supplements the SQLCODE value. SQLCA is not part of the
ANSI/ISO SQL standard. However, many foreign databases such
as DB2 and ORACLE RDBMS have defined proprietary semantics and
syntax to implement it.

o SQLSTATE-This is the error handling mechanism for the ANSI/ISO
SQL standard. The SQLSTATE value is a character string that is
associated with diagnostic information. To use the SQLSTATE
status parameter, you must specify the SQL92 dialect and
compile your module using DEC Rdb Version 6.0.
--------------------------------------------------------------------

Andreas

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Luis Alberto Amigo Navarro 2002-07-18 08:18:35 Re: [HACKERS] why is postgres estimating so badly?
Previous Message Christopher Kings-Lynne 2002-07-18 05:48:51 Bright ideas required for drop column...