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 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org