Tom Lane wrote:
> I wrote:
>> In any case, that's orthogonal to the part that I was focusing on,
>> which was to try to prevent error recursion as a result of trouble
>> in the encoding conversion subsystem. It looks like we could do that
>> with some additional hacking in send_message_to_frontend() to avoid
>> conversion, as well as translation, when in_error_recursion_trouble()
>> is true. Your point about there possibly being non-ASCII user-inserted
>> data in the message is a bit troubling, but for the cases where
>> recursion is actually occurring I don't think that that will happen.
>
> Here is a proposed patch that does this. It largely reverts my patch
> of 2008-10-27 in favor of a more general policy that says that *all*
> localization of error messages is disabled once we get into error
> recursion trouble. Having done that, we can reasonably assume that
> the error message text is 7-bit ASCII, and therefore bypass encoding
> conversion as well. This fixes the example reported in bug #4680
> (even without the subsequent patch to prevent that case from arising),
> and it still prevents the cases that my previous patch was meant to
> deal with.
>
> Comments, objections?
Looks ok to me. I'm still a bit uneasy about the assumption that the
error message is 7-bit ACII. Maybe that's just because I don't fully
understand all the conditions how we can end up in recursion, so I would
still put something into pq_send_raw_string to check that the string
really is 7-bit ASCII. Just in case. Maybe clear all the high bits, or
replace non-ASCII characters with question marks.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
