On Thu, 2003-03-13 at 15:51, Tom Lane wrote: > After digging through our many past discussions of what to do with error > messages, I have put together the following first-cut proposal.
Great work, Tom! While we're effectively changing every elog call site in the backend, would it also be a good idea to adopt a standard for the format of error messages? (e.g. capitalization, grammar, etc.) > extern int errmsg_internal(const char *fmt, ...); > > Like errmsg() except that the first parameter is not subject to > gettext-ification. My thought is that this would be used for internal > can't-happen conditions; there's no need to make translators labor over > translating stuff like "eval_const_expressions: unexpected boolop %d", > nor even to make them think about whether they need to. If we wanted to get fancy, we could make use of the glibc ability to generate a back trace programatically: http://www.gnu.org/manual/glibc-2.2.5/html_node/Backtraces.html#Backtraces > In gcc-compiled > backends, the function name will be provided automatically by errstart, > but there will be some places where we need the name to be available even > in a non-gcc build. To be honest, I'd be sceptical whether there are enough platforms without *either* gcc or a C99 compiler that it's worthwhile worrying about them that much (all that is at stake is some backward compatibility, anyway). Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
