Re: additional json functionality

On Fri, Nov 15, 2013 at 4:31 PM, Hannu Krosing <hannu(at)2ndquadrant(dot)com> wrote:
>>>> I think we need to take a *very* hard look at #3 before exploring #1
>>>> or #2: Haven't through it through yet but it may be possible to handle
>>>> this in such a way that will be mostly transparent to the end user and
>>>> may have other benefits such as a faster path for serialization.
>>> If it’s possible to preserve order and still get the advantages of binary representation --- which are substantial (see http://theory.so/pg/2013/10/23/testing-nested-hstore/ and http://theory.so/pg/2013/10/25/indexing-nested-hstore/ for a couple of examples) --- without undue maintenance overhead, then great.
>>>
>>> I am completely opposed to duplicate key preservation in JSON, though. It has caused us a fair number of headaches at $work.
> Let's just change the current json-constructing functions return type to
> json_text which is exactly like text with 2 extra properties:
>
> 1) it is syntax-checked for valid json (that is it can be cast to json)
>
> and
>
> 2) if included in outer json as data, it is included directly and is not
> quoted like text
>
>
> With just these two it should possible to have the following
>
> a) Merlin and others can keep (ab)using json_text as this
> wonderfully versatile format for feeding json parsers and
> visualisers which accept duplicates and consider order significant
>
> b) cast this to binary json object if de-duplication and fast access to
> internals is needed
>
> I do not think we need anything else for this

I think you may be on to something here. This might also be a way
opt-in to fast(er) serialization (upthread it was noted this is
unimportant; I'm skeptical). I deeply feel that two types is not the
right path but I'm pretty sure that this can be finessed.

> As far as I understand merlin is mostly ok with stored json being
> normalised and the problem is just with constructing "extended"
> json (a.k.a. "processing instructions") to be used as source for
> specialised parsers and renderers.

yes, this is correct.

merlin