On Tue, Dec 20, 2011 at 00:26, David E. Wheeler <da...@kineticode.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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
