2012/1/11 Robert Haas <robertmh...@gmail.com>: > On Wed, Jan 11, 2012 at 8:38 AM, Pavel Stehule <pavel.steh...@gmail.com> > wrote: >> I don't understand why we have to do it? >> >> We don't support similar functionality for XML, so why for JSON? > > Hrm. Well, that's an interesting point. Maybe we don't. I assumed > that people would eventually want to optimize queries of the form > SELECT whatever FROM tab WHERE jsoncol = 'constant'. If that's a > sufficiently marginal use case that we don't care, then fine. > > One difference between JSON and XML is that XML really has no > well-defined comparison semantics. For example, consider: > > <foo><bar>1.0</bar></foo> > <foo><bar>1.0</bar> </foo> > > If the XML is being used as a transport mechanism, then the extra > space is semantically insignificant, but if this is markup, then it > might matter a lot. Also, consider: > > <foo><bar>1.00</bar></foo> > > That one might be equal if we think 1.0 is intended to be a number, > but if it's intended as a string then it's not. We could perhaps do > comparisons in XML relative to some DTD or schema if those provide > details about what the values mean, but in a vacuum it's not > well-defined. On the other hand, in JSON, it's pretty clear that { 1, > 2, 3 } is the same value as {1,2,3} but "1,2,3" is different from "1, > 2, 3". There are some borderline cases that might need some sweat, > like whether 1 = 1.0 = 1.00 = 1e0, but in general the level of > ambiguity seems to me to be much less, making it more feasible here > than it would be for XML. > > That having been said, uncertainties about whether we want this at all > (and if so in what form) are exactly why I didn't include this kind of > stuff in the patch to begin with, and I think that if we get this much > committed for 9.2 we'll be doing pretty well. If we can agree on and > do more, great; if not, we'll at least have this much, which IMHO > would be an improvement over what we have now. >
I understand it now. My opinion is so some operators and index search can be in 9.2 - so use a JSON just as communication format now. * we need to build JSON * we need to check if some is valid JSON * we need to store JSON other steps should be (9.2) * basic operators eq, neeq * some tool like XQuery - simple query on JSON document available from SQL that can be used for functional indexes. > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers