Re: JSON for PG 9.2 - Mailing list pgsql-hackers

On Sun, Dec 18, 2011 at 10:49, Jan Urbański <wulczer@wulczer.org> wrote:
> On 18/12/11 04:21, Robert Haas wrote:
>> On Sat, Dec 17, 2011 at 7:50 PM, David E. Wheeler <david@kineticode.com> wrote:
>>> Love having the start here. I forwarded this message to Claes Jakobsson, creator of the jansson-using pg-json
extension.He’s a bit less supportive. He gave me permission to quote him here: 
>>>
>>>> Frankly I see the inclusion of a JSON datatype in core as unnecessary. Stuff should be moved out of core rather
thanin, as we do in Perl. Also, does this patch mean that the 'json' type is forever claimed and can't be replaced by
extensions?
>>>>
>>>> There's little reason to reimplement JSON parsing, comparision and other routines when there's a multitude of
alreadygood libraries. 
>>
>> That's fair enough, but we've had *many* requests for this
>> functionality in core, I don't see what we lose by having at least
>> some basic functionality built in.
>
> I think having a JSON data type in core would drastically limit the
> exposure third-party JSON extensions would get and that's bad. There are

The same way that having replication in core is bad for the rest of
the replication engines? While it has certainly decreased the usage of
for example Slony, I don't think anybody can say it's a bad thing that
we have this in core...

And of course, *not* having it in core, we didn't have people claiming
for many years that "postgres has no replication" or anything like
that... The fact is that a *lot* of our users, particularly in large
companies, will never install an extension that's not part of core.
Just look at other discussions about it even being a problem with it
being in *contrib*, which is still maintained and distributed by the
same developers.

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)

So I'm not sure it would really lessen the exposure much at all -
those that are willing to install such extensions already, are surely
capable of finding it themselves (using pgxn for example - or even
google)


> tons of interesting features a JSON type could have and tying its
> development to a one year release cycle might be a disservice both for
> people who are willing to provide these features earlier, the users
> which are faced with a choice between a fast-moving third-party addon
> and a blessed core type and would cause overall confusion.

And the other option would be to *only* have a fast-moving third-party
addon, which simply disqualifies it completely in many environments.

Keeping it as a third party addon is better for the developer. Keeping
it in core is better for the user (if the user is a large company -
not a hacker).

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.

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