Skip site navigation (1) Skip section navigation (2)

Re: JSON for PG 9.2

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Joey Adams <joeyadams3(dot)14159(at)gmail(dot)com>
Cc: Abhijit Menon-Sen <ams(at)toroid(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Claes Jakobsson <claes(at)surfar(dot)nu>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Jan Urbański <wulczer(at)wulczer(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org, Jan Wieck <janwieck(at)yahoo(dot)com>
Subject: Re: JSON for PG 9.2
Date: 2012-02-01 16:28:50
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
On Tue, Jan 31, 2012 at 3:47 PM, Joey Adams <joeyadams3(dot)14159(at)gmail(dot)com> wrote:
> I'm mostly in favor of allowing \u0000.  Banning \u0000 means users
> can't use JSON strings to marshal binary blobs, e.g. by escaping
> non-printable characters and only using U+0000..U+00FF.  Instead, they
> have to use base64 or similar.

I agree.  I mean, representing data using six bytes per source byte is
a bit unattractive from an efficiency point of view, but I'm sure
someone is going to want to do it.  It's also pretty clear that JSON
string -> PG text data type is going to admit of a number of error
conditions (transcoding errors and perhaps invalid surrogate pairs) so
throwing one more on the pile doesn't cost much.

Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2012-02-01 17:18:59
Subject: Re: Should I implement DROP INDEX CONCURRENTLY?
Previous:From: Tom LaneDate: 2012-02-01 16:04:15
Subject: Re: BUG #6425: Bus error in slot_deform_tuple

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group