Re: JSON for PG 9.2

On Tue, Dec 13, 2011 at 1:13 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On Tue, Dec 13, 2011 at 2:41 PM, Peter Eisentraut <peter_e(at)gmx(dot)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.

To the best of my knowledge:

libv8 is also exception-free, and compiled with exceptions off. plv8
does make use of exceptions, though, something that gave me pause when
reading it. At first I thought it was to integrate with libv8, but
that did not seem to be the case, so it probably could learn to use
return codes instead. libv8 also has a light dependency list:

ldd /usr/lib/libv8.so (/lib/ entries and linux omitted)

libicuuc.so.44 => /usr/lib/libicuuc.so.44 (0x00007fc838459000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fc838151000)
libicudata.so.44 => /usr/lib/libicudata.so.44 (0x00007fc836aed000)

So ICU and C++.

In addition, more projects have been successful in embedding libv8;
right now it has the entrenchment advantage over libmozjs in
applications that are not closely tied to XUL/Mozilla, although that
could change in a few years. Institutionally Mozilla has not
historically been quick to prioritize anything not essential to
shipping Firefox, and I would imagine V8 is in a similar situation,
even though they occasionally make concessions for non-browsing use
cases (ex: multi-gigabyte heap sizes).

I would regard either choice as at least equally risky in this way,
given what I know (refinements welcome).

Both libv8 and libmozjs are maintained in Debian, and are parts of at
least one stable release.

In spite of the hazard posed by the aggressive releases and
non-general-purpose focus of the maintainers of both of these runtimes
at this time, I am still in favor of having a binding to at least one
of them into mainline, with the ability to get new or alternative
versions via extensions. If extensions were already pervasive and
everyone was installing them everywhere I'd think otherwise (just
leave it as an extension), but the cost of not being able to index and
manipulate JSON efficiently and with a trusted language is just too
huge to let slide.

Right now the perception of Postgres...actually, databases in general,
including virtually all of the newcomers -- is that they are
monolithic systems, and for most people either "9.3" will "have"
javascript and indexing of JSON documents, or it won't. In most cases
I would say "meh, let them eat cake until extensions become so
apparently dominant that we can wave someone aside to extension-land",
but in this case I think that would be a strategic mistake.

--
fdr