On 11/20/2013 07:52 AM, Robert Haas wrote:
On Tue, Nov 19, 2013 at 1:43 PM, David Johnston <pol...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
