Re: additional json functionality

On 11/15/2013 01:12 PM, David E. Wheeler wrote:
> On Nov 15, 2013, at 12:37 PM, Andrew Dunstan <andrew(at)dunslane(dot)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 being remotely 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 all convinced 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