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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers