From: | Joey Adams <joeyadams3(dot)14159(at)gmail(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Florian Pflug <fgp(at)phlo(dot)org>, 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-24 03:09:45 |
Message-ID: | CAARyMpDVTkCH2m7mhjXwrrwpEY1EVX=80FT-+NKp8Yvf_Zzayg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Also, should I forbid the escape \u0000 (in all database encodings)?
Pros:
* If \u0000 is forbidden, and the server encoding is UTF-8, then
every JSON-wrapped string will be convertible to TEXT.
* It will be consistent with the way PostgreSQL already handles text,
and with the decision to use database-encoded JSON strings.
* Some applications choke on strings with null characters. For
example, in some web browsers but not others, if you pass
"Hello\u0000world" to document.write() or assign it to a DOM object's
innerHTML, it will be truncated to "Hello". By banning \u0000, users
can catch such rogue strings early.
* It's a little easier to represent internally.
Cons:
* Means JSON type will accept a subset of the JSON described in
RFC4627. However, the RFC does say "An implementation may set limits
on the length and character contents of strings", so we can arguably
get away with banning \u0000 while being law-abiding citizens.
* Being able to store U+0000–U+00FF means users can use JSON strings
to hold binary data: by treating it as Latin-1.
- Joey
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-07-24 03:14:50 | Re: Initial Review: JSON contrib modul was: Re: Another swing at JSON |
Previous Message | Jeff Janes | 2011-07-24 01:50:34 | Re: pgbench cpu overhead (was Re: lazy vxid locks, v1) |