| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
| 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-02-24 17:49:03 |
| Message-ID: | 11386.1582566543@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I wrote:
> [ unicode-escapes-with-other-server-encodings-2.patch ]
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.
regards, tom lane
| Attachment | Content-Type | Size |
|---|---|---|
| unicode-escapes-with-other-server-encodings-3.patch | text/x-diff | 53.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Fetter | 2020-02-24 17:53:34 | Re: Error on failed COMMIT |
| Previous Message | Pavel Stehule | 2020-02-24 17:47:17 | Re: plan cache overhead on plpgsql expression |