Re: Upgrading the backend's error-message infrastructure

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