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
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 |