From 1b0c30f68de7af7511b5a2c7297ff55c29a84db6 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Mon, 27 Oct 2008 19:37:42 +0000 Subject: Install a more robust solution for the problem of infinite error-processing recursion when we are unable to convert a localized error message to the client's encoding. We've been over this ground before, but as reported by Ibrar Ahmed, it still didn't work in the case of conversion failures for the conversion-failure message itself :-(. Fix by installing a "circuit breaker" that disables attempts to localize this message once we get into recursion trouble. Patch all supported branches, because it is in fact broken in all of them; though I had to add some missing translations to the older branches in order to expose the failure in the particular test case I was using. --- doc/src/sgml/sources.sgml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'doc/src') diff --git a/doc/src/sgml/sources.sgml b/doc/src/sgml/sources.sgml index 0d51db1a4cd..bc7dee6ab06 100644 --- a/doc/src/sgml/sources.sgml +++ b/doc/src/sgml/sources.sgml @@ -1,5 +1,5 @@ @@ -179,7 +179,7 @@ ereport(ERROR, errmsg_internal(const char *msg, ...) is the same as errmsg, except that the message string will not be - included in the internationalization message dictionary. + translated nor included in the internationalization message dictionary. This should be used for can't happen cases that are probably not worth expending translation effort on. @@ -255,7 +255,7 @@ elog(level, "format string", ...); ereport(level, (errmsg_internal("format string", ...))); Notice that the SQLSTATE errcode is always defaulted, and the message - string is not included in the internationalization message dictionary. + string is not subject to translation. Therefore, elog should be used only for internal errors and low-level debug logging. Any message that is likely to be of interest to ordinary users should go through ereport. Nonetheless, -- cgit v1.2.3