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

From Peter Eisentraut
Subject Re: JSON for PG 9.2
Date
Msg-id 1323808872.16048.16.camel@vanquo.pezone.net
Whole thread Raw
In response to Re: JSON for PG 9.2  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: JSON for PG 9.2  (Merlin Moncure <mmoncure@gmail.com>)
Re: JSON for PG 9.2  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
On tis, 2011-12-13 at 08:44 -0500, Robert Haas wrote:
> Just because all our languages are Turing-complete doesn't mean they
> are all equally well-suited to every task.  Of course, that doesn't
> mean we'd add a whole new language just to get a JSON parser, but I
> don't think that's really what Peter was saying.

That was in fact what I was saying.

> Rather, I think the
> point is that embedded Javascript is *extremely* popular, lots and
> lots of people are supporting it, and we ought to seriously consider
> doing the same.  It's hard to think of another PL that we could add
> that would give us anywhere near the bang for the buck that Javascript
> would.

If JavaScript (trademark of Oracle, btw.; be careful about calling
anything PL/JavaScript) had a near-canonical implementation with a
stable shared library and a C API, then this might be a no-brainer.  But
instead we have lots of implementations, and the one being favored here
is written in C++ and changes the soname every 3 months.  I don't think
that's the sort of thing we want to carry around.

The way forward here is to maintain this as an extension, provide debs
and rpms, and show that that is maintainable.  I can see numerous
advantages in maintaining a PL outside the core; especially if you are
still starting up and want to iterate quickly.




pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: xlog location arithmetic
Next
From: Bruce Momjian
Date:
Subject: Re: JSON for PG 9.2