Subject: Re: PG 13 release notes, first draft
To: Bruce Momjian <bruce@momjian.us>,
 John Naylor <john.naylor@2ndquadrant.com>
References: <20200505031600.GB21752@momjian.us>
 <CACPNZCugECZv_5TNFFQ+R9Pp15PP5426oAstC1g7kTS1aLgrnw@mail.gmail.com>
 <20200505143118.GH21752@momjian.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
From: Chapman Flack <chap@anastigmatix.net>
Message-ID: <5EB317A8.1020907@anastigmatix.net>
Date: Wed, 6 May 2020 16:01:44 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <20200505143118.GH21752@momjian.us>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Precedence: bulk

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