Re: additional json functionality

On Nov 15, 2013, at 6:35 AM, Merlin Moncure <mmoncure@gmail.com> wrote:

> Here are the options on the table:
> 1) convert existing json type to binary flavor (notwithstanding objections)
> 2) maintain side by side types, one representing binary, one text.
> unfortunately, i think the text one must get the name 'json' due to
> unfortunate previous decision.
> 3) merge the behaviors into a single type and get the best of both
> worlds (as suggested upthread).
>
> 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
coupleof 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.

Best,

David