On 11/15/2013 01:12 PM, David E. Wheeler wrote:
> On Nov 15, 2013, at 12:37 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>
>> It's making my head hurt, to be honest, and it sounds like a recipe for years and years of inconsistencies and
bugs.
>>
>> 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
beingremotely acceptable to have behaviour depend in whether or not something was ever stored, which is what this looks
like.
>
> I disklike having two types (no, three -- there is hstore, too!). But if there is consensus for it (and I am not at
allconvinced that there is at this point), I can live with it. Docs would have to be pretty explicit, though.
I would be happy to do a survey on how common key ordering and/or
duplicate keys are in postgresql+json. However, I'm not clear on what
set of survey responses would decide us in either direction. Even as a
pool of one, Merlin's case is a pretty persuasive example ... and, as he
points out, there will be applications built around 9.3's JSON which
havent even been written yet.
I believe this was a danger we recognized when we added the JSON type,
including the possibility that a future binary type might need to be a
separate type due to compatibility issues. The only sad thing is the
naming; it would be better for the new type to carry the JSON name in
the future, but there's no way to make that work that I can think of.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
