Re: JSON for PG 9.2
От | Robert Haas |
---|---|
Тема | Re: JSON for PG 9.2 |
Дата | |
Msg-id | CA+TgmoZZY5WicSsDGJwgYJU2wRXwcwWftBdC5DQ1WHHcHWuyqw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: JSON for PG 9.2 (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: JSON for PG 9.2
|
Список | pgsql-hackers |
On Wed, Jan 11, 2012 at 8:38 AM, Pavel Stehule <pavel.stehule@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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: