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

Re: JSON for PG 9.2

From: Abhijit Menon-Sen <ams(at)toroid(dot)org>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Joey Adams <joeyadams3(dot)14159(at)gmail(dot)com>,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-02 09:54:59
Message-ID: 20120202095459.GB779@toroid.org (view raw or flat)
Thread:
Lists: pgsql-hackers
At 2012-02-01 11:28:50 -0500, robertmhaas(at)gmail(dot)com wrote:
>
> 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.

Hi Robert.

I'm sorry for being slow, but I don't understand what you're proposing
to do here (if anything). Could I ask you to explain, please?

Are you talking about allowing the six literal bytes "\u0000" to be
present in the JSON? If so, I agree, there seems to be no reason to
disallow it.

Are you also saying we should allow any "\uNNNN" sequence, without
checking for errors (e.g. invalid surrogate pairs or parts thereof)?

And what transcoding errors are you referring to?

-- ams

In response to

Responses

pgsql-hackers by date

Next:From: Marti RaudseppDate: 2012-02-02 10:16:26
Subject: Re: [PATCH] Fix float8 parsing of denormal values (on some platforms?)
Previous:From: Heikki LinnakangasDate: 2012-02-02 09:47:43
Subject: Re: Refactoring log_newpage

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