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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company