Re: Unicode escapes with any backend encoding

From: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Chapman Flack <chap(at)anastigmatix(dot)net>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Unicode escapes with any backend encoding
Date: 2020-01-14 22:50:32
Message-ID: CAA8=A7_9swLMxBTtb9dOFtYOmQycutUCWisajaGSQLo9Rw+WpA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 15, 2020 at 7:55 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
> > On Wed, Jan 15, 2020 at 4:25 AM Chapman Flack <chap(at)anastigmatix(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2020-01-14 22:53:18 Re: Disallow cancellation of waiting for synchronous replication
Previous Message Alexander Korotkov 2020-01-14 22:47:30 Re: Avoid full GIN index scan when possible