Re: ERRORDATA_STACK_SIZE exceeded (server crash)

I wrote:
> This is still not very nice because what the user would get is
> a complaint about ERRORDATA_STACK_SIZE exceeded with no hint that
> he's got an encoding problem. It'd be better if we could get the
> disable-gettext-and-FATAL-out behavior to apply to the "character
> has no equivalent" error message, but I'm not sure how we do that
> without bollixing up less-critical occurrences of that message.

After poking around a bit I decided that this could be done in a not
horrendously ugly way if we are willing to make a couple more places
know about escaping from error recursion situations. Attached is a
proposed patch that prevents the crash shown previously. BTW, a better
stress test for this is to set LANG = tr_TR.utf8, client_encoding =
latin1, and then try "select E'\305\237';". That's because the
"character has no equivalent" message isn't itself translated in the
present ko translation, but it is in the tr translation. My first-cut
patch worked for the ko case and not the tr case :-(

One thing that is still a bit ugly about this patch is the hack in
wchar.c to ensure that the "character has no equivalent" message
doesn't get translated:

* ... Note that we have to
* spell the message slightly differently, which we do by sticking a
* space on the end --- using errmsg_internal() doesn't actually keep
* elog.c from calling gettext, it only prevents the string from being
* entered into the translation lists.

It might be better to modify elog.c so that errmsg_internal really
doesn't call gettext. This would require kluging up EVALUATE_MESSAGE()
a bit, so I'm not quite sure which is cleaner. Thoughts?

regards, tom lane