| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, 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-02-25 03:43:15 |
| Message-ID: | CA+TgmoatJdaFZdynTRr+0Vga1f1B4_vxk3PVY97E8uNxyRzudA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Feb 24, 2020 at 11:19 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I see this patch got sideswiped by the recent refactoring of JSON
> lexing. Here's an attempt at fixing it up. Since the frontend
> code isn't going to have access to encoding conversion facilities,
> this creates a difference between frontend and backend handling
> of JSON Unicode escapes, which is mildly annoying but probably
> isn't going to bother anyone in the real world. Outside of
> jsonapi.c, there are no changes from v2.
For the record, as far as JSON goes, I think I'm responsible for the
current set of restrictions, and I'm not attached to them. I believe I
was uncertain of my ability to implement anything better than what we
have now and also slightly unclear on what the semantics ought to be.
I'm happy to see it improved, though.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2020-02-25 03:57:05 | Re: Function to track shmem reinit time |
| Previous Message | Justin Pryzby | 2020-02-25 03:35:32 | Re: explain HashAggregate to report bucket and memory stats |