Skip site navigation (1) Skip section navigation (2)

Re: JSON for PG 9.2

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Claes Jakobsson <claes(at)surfar(dot)nu>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net>, Jan Urbański <wulczer(at)wulczer(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Joey Adams <joeyadams3(dot)14159(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>, Jan Wieck <janwieck(at)yahoo(dot)com>
Subject: Re: JSON for PG 9.2
Date: 2012-01-11 14:41:45
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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:
> The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Aidan Van DykDate: 2012-01-11 14:47:17
Subject: Re: [WIP] Double-write with Fast Checksums
Previous:From: Andres FreundDate: 2012-01-11 14:25:13
Subject: Re: checkpoint writeback via sync_file_range

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group