Re: Unicode escapes with any backend encoding - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Unicode escapes with any backend encoding
Date
Msg-id CAA8=A7_9swLMxBTtb9dOFtYOmQycutUCWisajaGSQLo9Rw+WpA@mail.gmail.com
Whole thread Raw
In response to Re: Unicode escapes with any backend encoding  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Unicode escapes with any backend encoding  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Jan 15, 2020 at 7:55 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> > On Wed, Jan 15, 2020 at 4:25 AM Chapman Flack <chap@anastigmatix.net> wrote:
> >> On 1/14/20 10:10 AM, Tom Lane wrote:
> >>> to me that this error is just useless pedantry.  As long as the DB
> >>> encoding can represent the desired character, it should be transparent
> >>> to users.
>
> >> That's my position too.
>
> > and mine.
>
> I'm confused --- yesterday you seemed to be against this idea.
> Have you changed your mind?
>
> I'll gladly go change the patch if people are on board with this.
>
>

Perhaps I expressed myself badly. What I meant was that we should keep
the json and text escape rules in sync, as they are now. Since we're
changing the text rules to allow resolvable non-ascii unicode escapes
in non-utf8 locales, we should do the same for json.

cheers

andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Avoid full GIN index scan when possible
Next
From: Andres Freund
Date:
Subject: Re: Disallow cancellation of waiting for synchronous replication