Horton

Re: JSON for PG 9.2

Pavel Stehule <pavel.stehule@gmail.com>

View thread
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: "David E. Wheeler" <david@kineticode.com>, Claes Jakobsson <claes@surfar.nu>, Dimitri Fontaine <dimitri@2ndquadrant.fr>, Merlin Moncure <mmoncure@gmail.com>, Andrew Dunstan <andrew@dunslane.net>, Magnus Hagander <magnus@hagander.net>, Jan Urbański <wulczer@wulczer.org>, Simon Riggs <simon@2ndquadrant.com>, Joey Adams <joeyadams3.14159@gmail.com>, Bruce Momjian <bruce@momjian.us>, PostgreSQL-development Hackers <pgsql-hackers@postgresql.org>, Jan Wieck <janwieck@yahoo.com>
Date: 2012-01-11T13:38:21Z
Lists: pgsql-hackers 
2012/1/11 Robert Haas <robertmhaas@gmail.com>:
> On Wed, Jan 11, 2012 at 1:18 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> 2012/1/11 Robert Haas <robertmhaas@gmail.com>:
>>> On Tue, Dec 20, 2011 at 9:06 PM, David E. Wheeler <david@kineticode.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.
>

I don't understand why we have to do it?

We don't support similar functionality for XML, so why for JSON?

Pavel

> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company