On Fri, Nov 15, 2013 at 4:31 PM, Hannu Krosing <ha...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers