From: johnnnnnn <john@phaedrusdeinus.org>
To: pgsql-hackers@postgresql.org
Subject: Re: Upgrading the backend's error-message infrastructure
Date: Fri, 14 Mar 2003 12:24:43 -0600
Message-ID: <20030314182443.GH74817@performics.com> (raw)
In-Reply-To: <22063.1047662584@sss.pgh.pa.us>
References: <9168.1047588660@sss.pgh.pa.us>
<20030314161922.GG74817@performics.com>
<22063.1047662584@sss.pgh.pa.us>
On Fri, Mar 14, 2003 at 12:23:04PM -0500, Tom Lane wrote:
> > It would seem to make more sense to me to provide a different
> > function(s) which allows the lookup Messages, Details, and Hints
> > based on the SQLSTATE.
>
> This would constrain us to have a different SQLSTATE for every error
> message, which we aren't going to do.
That makes sense -- i was assuming a one-to-one mapping (or, at least,
many-to-one in the other direction: many SQLSTATEs for the same
"Unknown error" message).
I'm not sure i follow the reasoning behind allowing multiple messages
for a single SQLSTATE, though. I would think that having the
machine-readable portion of the error be the most granular would make
sense. I can't imagine the SQLSTATE space being too small for us at
this point.
If it's different enough to warrant a different message, then, in my
mind, it's different enough to warrant a different SQLSTATE.
> It's also unclear how you insert parameters into error strings if
> you do this.
That's valid, but there are other ways of dealing with it. The
position in the SQL statement has been moved out to another item in
the response, so why not move the table, column, index, or whatnot
into another item(s) as well?
> > - Removal of localization from error/notice generation
> > libraries. This should make that section of code simpler and more
> > fault-tolerant.
>
> And you put it where, instead?
Sorry, i think i phrased that poorly. What i meant was that the
functions which provide lookups would need to be aware of locale
because they're referencing localized strings. The functions which are
specifically generating and transmitting the errors, on the other
hand, would be free of localized strings, so would not have to rely on
any of the locale infrastructure at all.
I'm not suggesting any change in the scheme for localization or
anything like that, just saying that limiting the internal access
points might make things cleaner.
The usual other benefits should result as well: simpler unit tests,
easier maintenance, etc.
-johnnnnnnnnnnnn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: john@phaedrusdeinus.org, pgsql-hackers@postgresql.org
Subject: Re: Upgrading the backend's error-message infrastructure
In-Reply-To: <20030314182443.GH74817@performics.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox