Re: JSON for PG 9.2

2012/1/11 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Wed, Jan 11, 2012 at 8:38 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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