Hannu Krosing-3 wrote
> 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.
Three things:
1) How would this work in the face of functions that erase typemod
information?
2) json [no type mod] would have to effectively default to json(string)?
3) how would #1 and #2 interact?
I pondered the general idea but my (admittedly limited) gut feeling is that
using typemod would possibly be technically untenable and from an end-user
perspective would be even more confusing than having two types.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/additional-json-functionality-tp5777975p5779428.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.