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

Re: JSON for PG 9.2

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: "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>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net>, Jan Urbański <wulczer(at)wulczer(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Joey Adams <joeyadams3(dot)14159(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>, Jan Wieck <janwieck(at)yahoo(dot)com>
Subject: Re: JSON for PG 9.2
Date: 2012-01-11 13:33:53
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Jan 11, 2012 at 1:18 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> 2012/1/11 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> On Tue, Dec 20, 2011 at 9:06 PM, David E. Wheeler <david(at)kineticode(dot)com> wrote:
>>> On Dec 20, 2011, at 10:39 AM, Claes Jakobsson wrote:
>>>> Are people explicitly asking for a) *JSON* datatype or b) a type that lets you store arbitrary complex semi-untyped data structures?
>>> Yes.
>>>> if b) then this might get a lot more interesting
>>> JSON is the most popular/likely way to represent that, I think.
>> On that note, here's an updated version of the patch I posted
>> upthread, with some regression tests and minimal documentation.
> I like this patch and this feature.
> I see only one issue - there is not functionality that helps generate
> JSON in pg.
> What do you think about functions: array_to_json(anyarray),
> row_to_json(any) and format_json(text, text, ...)

I think we might want all of that stuff, but I doubt there is time to
do it for 9.2.

Actually, I think the next logical step would be to define equality
(is there an official definition of that for JSON?) and build a btree
opclass.  I believe the code I've already written could be extended to
construct an abstract syntax tree for those operations that need it.
But we need to make some decisions first.  A btree opclass requires a
total ordering, so we have to arbitrarily define whether 1 < true, 1 <
[1], 1 < "1", etc.

Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Pavel StehuleDate: 2012-01-11 13:38:21
Subject: Re: JSON for PG 9.2
Previous:From: Pavel StehuleDate: 2012-01-11 13:32:06
Subject: Re: JSON for PG 9.2

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