Re: additional json functionality

On 11/17/2013 10:51 PM, Dimitri Fontaine wrote:
> "David E. Wheeler" <david(at)justatheory(dot)com> writes:
>> You know that both types support scalar values right? 'a'::JSON works now,
>> and 'a'::hstore works with the WIP patch. For that reason I would not think
>> that "doc" or "obj" would be good choices.
> I'm wondering about just pushing hstore in core (even if technically
> still an extension, install it by default, like we do for PLpgSQL), and
> calling it a day.
>
> If you need pre-9.4 JSON-is-text compatibility, use the json datatype,
> if you want something with general index support, use hstore.
+1 for getting also hstore in

I think hstore needs to keep its text format compatible with older hstore
(in this discussion lets call this text format "hson", short for
HStore Object Notation for added confusion :)
>
> For bikeshedding purposes, what about calling it jstore,
+1 for jstore as well. I am happy with jstore, jsdoc, jsobj

jstore/jsobj/jsdoc really is *not* JSON, but a bona-fide freeform
structured datatype that happens to have JSON as convenient
I/O format.

You may want to use jstore even if you have never needed
JSON as serialisation/transport format before.

I do not like jsonB (sounds too much like json2, i.e. like we were
trying to cover up a design accident) nor json_strict (as this is not
really strict as it indeed does accept scalars, not just Arrays/Lists
and Objects/Dictionaries as per JSON standard)
> as in “we actually know how to store your json documents”?
>
> Regards,

Cheers

--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ