Re: JSON for PG 9.2

On Tue, Dec 20, 2011 at 00:26, David E. Wheeler <david(at)kineticode(dot)com> wrote:
> 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.

Yes, that's why I said "few" not "none".

Though in my experience, most companies are a lot more restrictive
about addons to their database than addons to their development
environments.

And note that it's not PGXN that's the problem I'm pointing at,
neither is it CPAN or easy_install or gem. The problem is the
vulnerability of the addon, and the maintenance. Meaning if it has a
single maintainer, that's a whole different thing from being
maintained by the PGDG.

> 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.

I think we're talking about different things here. While we can
certainly provide support on specific modules, after that is entered
into the agreement with the customer, we won't support a customer who
just calls up and says "hey, I'm using module xyz which you've never
heard of, and it crashes my database, please come fix it now". Are you
saying you do that - providing SLAs, 24/7 and similar things, on
modules you didn't even know the customer was using?

And FWIW, I'm talking about the quality, and not the ecosystem as
well. I'm just saying it takes a lot more work to verify the quality
and maintenance of an external module - if it's part of postgresql,
you have *already* got a quality stamp and a maintenance promise from
that.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/