Re: JSON for PG 9.2

From: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Jan Urbański <wulczer(at)wulczer(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Joey Adams <joeyadams3(dot)14159(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Claes Jakobsson <claes(at)gluefinance(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>, Jan Wieck <janwieck(at)yahoo(dot)com>
Subject: Re: JSON for PG 9.2
Date: 2011-12-19 23:26:37
Message-ID: 7B73B08C-4EBF-48B4-8E5A-5EB2C5720660@kineticode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Dec 18, 2011, at 4:41 AM, Magnus Hagander wrote:

> We can hopefully get around this for the extensions in contrib (and
> reasonably well has already), but few large companies are going to be
> happy to go to pgxn and download an extension that has a single
> maintainer (not "the team", and in most cases not even "a team"),
> usually no defined lifecycle, no support, etc. (I'm pretty sure you
> won't get support included for random pgxn modules when you buy a
> contract from EDB, or CMD, or us, or PGX, or anybody really - wheras
> if it the datatype is in core, you *will* get this)

I support having a JSON type in core, but question the assertions here. *Some* organizations won’t use PGXN, usually because they require things through a different ecosystem (RPMs, .debs, StackBuilder, etc.). But many others will. There are a *lot* of companies out there that use CPAN, easy_install, and Gem. The same sorts of places will use PGXN.

Oh, and at PGX, we’ll happily provide support for random modules, so long as you pay for our time. We’re not picky (and happy to send improvements back upstream), though we might recommend you switch to something better. But such evaluations are based on quality, not simply on what ecosystem it came from.

> If we can find a way to have a stable part in core and then have
> addons that can provide these "tons of interesting features" (which I
> agree there are) until such time that they can be considered stable
> enough for core, I think that's the best compromise.

+1, though I think the core type will at least need some basic operators and indexing support.

Best,

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2011-12-19 23:39:36 Re: JSON for PG 9.2
Previous Message Tom Lane 2011-12-19 23:26:03 Re: Lots of FSM-related fragility in transaction commit