Re: additional json functionality - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: additional json functionality
Date
Msg-id 528CB689.9070008@dunslane.net
Whole thread Raw
In response to Re: additional json functionality  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 11/20/2013 07:52 AM, Robert Haas wrote:
> On Tue, Nov 19, 2013 at 1:43 PM, David Johnston <polobo@yahoo.com> wrote:
>> IMO A reasonable default cast function should error if the json contents
>> require anything more than a straight parse to be stored into jsonb.  If the
>> user still needs to make the conversion we should have a standard and
>> configurable parser function with json input and jsonb output.  In this case
>> the key-keep options would be "keep first encountered" or "keep last
>> encountered" or "fail on duplicate" the last of which would be the default.
>>
>> I have not really pondered storing scalars into jsonb but before pondering
>> usability are there any technical concerns.  If the goal is to share the
>> backend with hstore then current hstore does not allow for this and so the
>> json aspect would either transfer back over or it would need customized
>> code.
> I confess to being a bit perplexed by why we want hstore and json to
> share a common binary format.  hstore doesn't store hierarchical data;
> json does.  If we design a binary format for json, doesn't that just
> obsolete store?  Why go to a lot of trouble to extend our home-grown
> format if we've got a standard format to plug into?
>
> The thing that's really missing in all of these discussions (AFAICS)
> is the issue of creating index support for these types.  If using some
> variant of the existing hstore format makes that easier, then I guess
> I understand the connection - but I'm not sure why or how that would
> be the case, and it would be nice to make the connection more
> explicit.
>


Oleg and Teodor have done quite a lot of work on a version of hstore 
that supports nested structures. See their pgcon talk. With some 
additions it has become in effect a non-standard notation for json. 
Rather than repeat that work, my suggestion has been that they abstract 
the common parts into a library that can be used by jsonb or whatever we 
end up calling it as well as nested hstore. I understand Teodor is 
working on this.

In general I share your feelings, though.

cheers

andrew



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Turning recovery.conf into GUCs
Next
From: Andres Freund
Date:
Subject: Re: Turning recovery.conf into GUCs