On 11/15/2013 01:12 PM, David E. Wheeler wrote: > On Nov 15, 2013, at 12:37 PM, Andrew Dunstan <and...@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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
