From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Peter van Hardenberg <pvh(at)pvh(dot)ca>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org, Joseph Adams <joeyadams3(dot)14159(at)gmail(dot)com> |
Subject: | Re: JSON for PG 9.2 |
Date: | 2011-12-13 20:41:12 |
Message-ID: | 1323808872.16048.16.camel@vanquo.pezone.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2011-12-13 20:57:23 | Re: JSON for PG 9.2 |
Previous Message | Robert Haas | 2011-12-13 20:37:10 | Re: xlog location arithmetic |