Content-Type: text/plain;
  charset="iso-8859-2"
From: Darko Prenosil <darko.prenosil@finteh.hr>
To: pgsql-hackers@postgreSQL.org
Subject: Re: Upgrading the backend's error-message infrastructure
Date: Fri, 14 Mar 2003 12:29:32 +0000
User-Agent: KMail/1.4.1
References: <9168.1047588660@sss.pgh.pa.us>
In-Reply-To: <9168.1047588660@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200303141229.32585.darko.prenosil@finteh.hr>

On Thursday 13 March 2003 20:51, Tom Lane wrote:
> (Or, protocol upgrade phase 1...)
>
> After digging through our many past discussions of what to do with error
> messages, I have put together the following first-cut proposal.  Fire at
> will...
>
>
> Objective
> ---------
>
> The basic objective here is to divide error reports into multiple
> fields, and in particular to include an "error code" field that gives
> applications a stable value to test against when they're trying to find
> out what went wrong.  (I am not spending much space in this proposal on
> the question of exactly what set of error codes we ought to have, but
> that comes soon.)  Peter Eisentraut argued cogently awhile back that the
> error codes ought not be hard-wired to specific error message texts,
> so this proposal treats them as separate entities.
>
>
What about user messages ?=20
If I remember correct, MSSQL had a system catalog table with formated error=
=20
messages, and it was possible to raise error with error number and it's=20
parameters. It can be very useful when you must raise same error from=20
different places in the code. It is very useful when you need to translate=
=20
error messages to another language for example. I think that there was a=20
range of error numbers reserved for user error messages.

Maybe even system messages can be stored in same way.=20
OK, there is problem how to raise an error if you can sp_connect and get th=
e=20
error message (because an error is in sp_connect) ???

Just an Idea (from M$) !