| From: | Florian Pflug <fgp(at)phlo(dot)org> |
|---|---|
| To: | Joey Adams <joeyadams3(dot)14159(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bernd Helmle <mailings(at)oopsware(dot)de>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, David Fetter <david(at)fetter(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com> |
| Subject: | Re: Initial Review: JSON contrib modul was: Re: Another swing at JSON |
| Date: | 2011-07-23 00:26:25 |
| Message-ID: | 83AB8CA7-1822-41FE-BF56-D3D6A88BB88A@phlo.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Jul23, 2011, at 00:04 , Joey Adams wrote:
> I think I've decided to only allow escapes of non-ASCII characters
> when the database encoding is UTF8. For example, $$"\u2013"$$::json
> will fail if the database encoding is WIN1252, even though WIN1252 can
> encode U+2013 (EN DASH). This may be somewhat draconian, given that:
>
> * SQL_ASCII can otherwise handle "any" language according to the documentation.
+1. It makes the handling if \uXXXX sequences consistent with the behaviour
of CHR(), which seems like a Good Thing. Clients can also work around this
restriction be de-escaping themselves, which shouldn't be too hard.
> * The XML type doesn't have this restriction (it just stores the
> input text verbatim, and converts it to UTF-8 before doing anything
> complicated with it).
Yeah. But the price the XML type pays for that is the lack of an
equality operator.
best regards,
Florian Pflug
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christopher Browne | 2011-07-23 02:10:51 | Re: Policy on pulling in code from other projects? |
| Previous Message | David Fetter | 2011-07-23 00:15:13 | Re: pgbench --unlogged-tables |