On 05/05/20 10:31, Bruce Momjian wrote:
> On Tue, May 5, 2020 at 09:20:39PM +0800, John Naylor wrote:
>> ... This patch is
>> about the server encoding, which formerly needed to be utf-8 for
>> non-ascii characters. (I think the client encoding doesn't matter as
>> long as ascii bytes are represented.)
>>
>> +<para>
>> +The UTF-8 characters must be available in the server encoding.
>> +</para>
>>
>> Same here, s/UTF-8/Unicode/.
>
> OK, new text is:
>
> Allow Unicode escapes, e.g., E'\u####', in clients that don't use UTF-8
> encoding (Tom Lane)
>
> The Unicode characters must be available in the server encoding.
>
> I kept the "UTF-8 encoding" since that is the only Unicode encoding we
> support.
My understanding also was that it matters little to this change what the
/client's/ encoding is.
There used to be a limitation of the server's lexer that would reject
Unicode escapes whenever the /server's/ encoding wasn't UTF-8 (even
if the server's encoding contained the characters the escapes represent).
I think that limitation is what was removed.
I don't think the client encoding comes into it at all. Sure, you could
just include the characters literally if they are in the client encoding,
but you might still choose to express them as escapes, and if you do they
get passed that way to the server for interpretation.
I had assumed the patch applied to all of the forms U&'\####',
U&'\+######', E'\u####', and E'\U######' but I don't think I read
the patch to be sure of that.
Regards,
-Chap