Re: JSON for PG 9.2

From: Joey Adams <joeyadams3(dot)14159(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: JSON for PG 9.2
Date: 2011-12-13 08:15:40
Message-ID: CAARyMpDzXxNjLOSgUCYu2sxfbLB6ZyNLeVR9CTaEv6xnNYUZSQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Dec 5, 2011 at 3:12 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Where are we with adding JSON for Postgres 9.2?  We got bogged down in
> the data representation last time we discussed this.

We should probably have a wiki page titled "JSON datatype status" to
help break the cycle we're in:

* Someone asks about the status of JSON

* Various ideas are suggested

* Patches are posted (maybe)

* More discussion about fundamental issues ensues

* Nothing is accomplished (as far as adding JSON to Postgres core)

There are several JSON implementations for Postgres floating around, including:

* http://pgxn.org/dist/pg-json/ : Mentioned in previous posts; a JSON
library based on Jansson supporting path subscript and equality
testing

* http://git.postgresql.org/gitweb/?p=json-datatype.git;a=summary :
The JSON datatype I implemented for Google Summer of Code 2010. It
has the most features of any implementation I'm aware of, but:

* Is in the form of a contrib module

* Preserves input text verbatim, a guarantee that will be broken
by more efficient implementations

* http://git.postgresql.org/gitweb/?p=json-datatype.git;a=shortlog;h=refs/heads/json2
: My rewrite of the JSON module that condenses input (but still
stores it as text) and addresses the issue of JSON when either the
server or client encoding is not UTF-8. Needs more features and
documentation, but like my other implementation, may not be quite what
we want.

Issues we've encountered include:

* Should JSON be stored as binary or as text?

* How do we deal with Unicode escapes and characters if the server or
client encoding is not UTF-8? Some (common!) character encodings have
code points that don't map to Unicode. Also, the charset conversion
modules do not provide fast entry points for converting individual
characters; each conversion involves a funcapi call.

---

In an application I'm working on, I store JSON-encoded objects in a
PostgreSQL database (using TEXT). I do so because it allows me to
store non-relational data that is easy for my JavaScript code to work
with.

However, I fail to see much benefit of a JSON type. When I need to
work with the data in PHP, C, or Haskell, I use JSON parsing libraries
available in each programming language. Although being able to
transform or convert JSON data within SQL might be convenient, I can't
think of any compelling reason to do it in my case.

Can someone clarify why a JSON type would be useful, beyond storage
and validation? What is a real-world, *concrete* example of a problem
where JSON manipulation in the database would be much better than:

* Using the application's programming language to manipulate the data
(which it does a lot already) ?

* Using CouchDB or similar instead of PostgreSQL?

- Joey

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Albe Laurenz 2011-12-13 09:57:49 Re: pgsql_fdw, FDW for PostgreSQL server
Previous Message Peter van Hardenberg 2011-12-13 08:06:22 Re: JSON for PG 9.2