Merlin Moncure-2 wrote
>> I don't want to have two types, but I think I'd probably rather have two
>> clean types than this. I can't imagine it being remotely acceptable to
>> have
>> behaviour depend in whether or not something was ever stored, which is
>> what
>> this looks like.
>
> Well, maybe so. My main gripe with the 'two types' solutions is that:
> 1) current type is already in core (that is, not an extension). In
> hindsight, I think this was a huge mistake.
> 2) current type has grabbed the 'json' type name and the 'json_xxx' API.
> 3) current type is getting used all over the place
>
> 'Two types' means that (AIUI) you can't mess around with the existing
> API too much. And the new type (due out in 2016?) will be something of
> a second citizen. The ramifications of dealing with the bifurcation
> is what makes *my* head hurt. Every day the json stuff is getting
> more and more widely adopted. 9.4 isn't going to drop until 2014 best
> case and it won't be widely deployed in the enterprise until 2015 and
> beyond. So you're going to have a huge code base operating on the
> 'legacy' json type.
>
> merlin
The current type can store the exact same data as what a hash-like type
could store. It can also store stuff a hash-like type would not be able to
store. From my reading the main reason for adding the new hash-like type
would be to increase the performance characteristics of using said type. So:
1) if reasonable performance can be had with the current type the new type
would be unnecessary
2) if #1 is not possible then the new type trades of leniency in format for
performance improvements
One implication of #2 is that existing json that wants the improved
performance will need to undergo a full-table rewrite in order to be
converted.
Both output textual representations are identical and function overloading
and API should be able to maintained substantially identical between the two
types.
David J
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/additional-json-functionality-tp5777975p5778628.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.