Re: additional json functionality

On 11/15/2013 02:59 PM, Merlin Moncure wrote:
> On Fri, Nov 15, 2013 at 4:31 PM, Hannu Krosing <hannu(at)2ndquadrant(dot)com> wrote:
> 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.

Thing is, I'm not particularly concerned about *Merlin's* specific use
case, which there are ways around. What I am concerned about is that we
may have users who have years of data stored in JSON text fields which
won't survive an upgrade to binary JSON, because we will stop allowing
certain things (ordering, duplicate keys) which are currently allowed in
those columns. At the very least, if we're going to have that kind of
backwards compatibilty break we'll want to call the new version 10.0.

That's why naming old JSON as "json_text" won't work; it'll be a
hardened roadblock to upgrading.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com