On 11/18/2013 06:49 PM, Josh Berkus wrote:
> On 11/18/2013 06:13 AM, Peter Eisentraut wrote:
>> On 11/15/13, 6:15 PM, Josh Berkus wrote:
>>> 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.
>> We could do something like SQL/XML and specify the level of "validity"
>> in a typmod, e.g., json(loose), json(strict), etc.
> Doesn't work; with XML, the underlying storage format didn't change.
> With JSONB, it will ... so changing the typemod would require a total
> rewrite of the table. That's a POLS violation if I ever saw one
We do rewrites on typmod changes already.
To me having json(string) and json(hstore) does not seem too bad.
Cheers
Hannu
