Re: JSON for PG 9.2
Merlin Moncure <mmoncure@gmail.com>
From: Merlin Moncure <mmoncure@gmail.com>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: Robert Haas <robertmhaas@gmail.com>, Peter van Hardenberg <pvh@pvh.ca>, Josh Berkus <josh@agliodbs.com>, pgsql-hackers@postgresql.org, Joseph Adams <joeyadams3.14159@gmail.com>
Date: 2011-12-13T21:13:59Z
Lists: pgsql-hackers
On Tue, Dec 13, 2011 at 2:41 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > 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. Mozilla SpiderMonkey seems like a good fit: it compiles to a dependency free .so, has excellent platform support, has a stable C API, and while it's C++ internally makes no use of exceptions (in fact, it turns them off in the c++ compiler). ISTM to be a suitable foundation for an external module, 'in core' parser, pl, or anything really. merlin