Re: additional json functionality

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: additional json functionality
Дата
Msg-id CAHyXU0y1XJJ_6oTPZ_LBxRm9fr70ofz78VQyX21ULErmjUc_Kg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: additional json functionality  (Hannu Krosing <hannu@2ndQuadrant.com>)
Список pgsql-hackers
On Fri, Nov 15, 2013 at 4:31 PM, Hannu Krosing <hannu@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
(seehttp://theory.so/pg/2013/10/23/testing-nested-hstore/ and http://theory.so/pg/2013/10/25/indexing-nested-hstore/
fora 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: additional json functionality
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_dump insert with column names speedup