Re: patch: Add JSON datatype to PostgreSQL (GSoC, WIP)

From: Terry Laurenzo <tj(at)laurenzo(dot)org>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: patch: Add JSON datatype to PostgreSQL (GSoC, WIP)
Date: 2010-11-09 23:11:44
Message-ID: AANLkTimhrUfXa3Fp5pkK14LojSVQ3OpUvSNX61G3nKNe@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert,
I think I agree. At a minimum, I would like to see the "chosen" of the
competing priorities live on as an outside module for use by previous
versions. Even having proposed one, and soon to be two of the competing
implementations, it makes me nervous to commit to one at this juncture.

I'm wrapping some items up this week but expect to have some time over the
next two weeks to complete my implementation.

Here's a quick status on where I'm at:
- Binary format has been implemented as specified here:
https://github.com/tlaurenzo/pgjson/blob/master/pgjson/jsonlib/BINARY-README.txt
- Hand coded a JSON-text lexer/parser and JSON-binary parser and
transcoders
- Ran out of time to do exhaustive tests, but typical payloads yield
significant space savings
- Based on an admittedly small number of test cases, I identified that
the process of encoding a string literal is the most expensive operation in
the general case, accounting for 1/2 to 2/3 of the time spent in a
transcoding operation. This is fairly obvious but good to know. I did not
spend any time looking into this further.
- Drastically simplified the code in preparation to build a stand-alone
module

As soon as I get a bit of time I was going to do the following:
- Create a simple PGXS based build, stripping out the rest of the bits I
was doodling on
- Re-implement the PG module based on the new jsonlib binary format and
parser
- Add JSONPath and some encoding bits back in from the original patch
- Do some holistic profiling between the JSON-as-Text approach and the
JSON-as-Binary approach

This is still a bit of a fishing expedition, imo and I would have a hard
time getting this ready for commit on Monday. If getting something in right
now is critical, Joey's original patch is the most complete at this point.

Terry

On Tue, Nov 9, 2010 at 3:48 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Mon, Nov 8, 2010 at 9:52 PM, Itagaki Takahiro
> <itagaki(dot)takahiro(at)gmail(dot)com> wrote:
> > Are there any activities in JSON data types for the next commitfest?
>
> I'm leaning toward the view that we shouldn't commit a JSON
> implementation to core (or contrib) for 9.1. We have at least three
> competing proposals on the table. I thought of picking it up and
> hacking on it myself, but then we'd have four competing proposals on
> the table. Even if we could come to some consensus on which of those
> proposals is technically superior, the rate at which new ideas are
> being proposed suggests to me that it would be premature to anoint any
> single implementation as our canonical one. I'd like to see some of
> these patches finished and put up on pgfoundry or github, and then
> consider moving one of them into core when we have a clear and stable
> consensus that one of them is technically awesome and the best thing
> we're going to get.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-11-09 23:30:58 Re: Protecting against unexpected zero-pages: proposal
Previous Message Cédric Villemain 2010-11-09 22:54:41 Re: multi-platform, multi-locale regression tests