Thread: PostgreSQL 13: native JavaScript Procedural Language support ?
Hi and hope this finds you well,
PostgreSQL has state of the art JSON(B) data type and query support, and basic updates as well, eg jsonb_set().
How about enabling users to do more advanced processing of JSON data inside the database itself, using JavaScript?
There's the PLV8 extension https://github.com/plv8/plv8
but it's not available for many major db providers (eg Heroku), making it hard to adopt it. Having it supported in the standard PostgreSQL distribution, besides the existing 4 languages (https://www.postgresql.org/docs/12/xplang.html), would be awesome!
Would you kindly consider this?
Thanks & stay safe,
Marius
Marius Andreiana <marius.andreiana@gmail.com> writes: > How about enabling users to do more advanced processing of JSON > data inside the database itself, using JavaScript? > There's the PLV8 extension https://github.com/plv8/plv8 > but it's not available for many major db providers (eg Heroku), making it > hard to adopt it. Having it supported in the standard PostgreSQL > distribution, besides the existing 4 languages ( > https://www.postgresql.org/docs/12/xplang.html), would be awesome! The core Postgres project doesn't have unlimited resources --- in fact, most of the time we feel desperately short of qualified developers. So we're not eager to pick up the maintenance burden for extensions that seem to be doing perfectly well on their own. (The extensions that do exist within the core distribution are largely there to make sure we don't break extensibility by accident.) Even if we did that, it would not automatically translate to downstream packagers enabling the feature; they might not want the additional dependencies. So the right thing for you to do is to lobby Heroku to include PLV8 in their offering. You'd have to convince them to support it in any case. regards, tom lane
Thanks Tom, that makes sense. Appreciate your time to explain the context.
I'll followup with Heroku.
Have a peaceful day,
Marius
On Wed, Mar 25, 2020 at 4:50 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Marius Andreiana <marius.andreiana@gmail.com> writes:
> How about enabling users to do more advanced processing of JSON
> data inside the database itself, using JavaScript?
> There's the PLV8 extension https://github.com/plv8/plv8
> but it's not available for many major db providers (eg Heroku), making it
> hard to adopt it. Having it supported in the standard PostgreSQL
> distribution, besides the existing 4 languages (
> https://www.postgresql.org/docs/12/xplang.html), would be awesome!
The core Postgres project doesn't have unlimited resources --- in fact,
most of the time we feel desperately short of qualified developers.
So we're not eager to pick up the maintenance burden for extensions
that seem to be doing perfectly well on their own. (The extensions
that do exist within the core distribution are largely there to make
sure we don't break extensibility by accident.)
Even if we did that, it would not automatically translate to downstream
packagers enabling the feature; they might not want the additional
dependencies.
So the right thing for you to do is to lobby Heroku to include PLV8
in their offering. You'd have to convince them to support it in
any case.
regards, tom lane
On Wed, Mar 25, 2020 at 05:46:27PM +0200, Marius Andreiana wrote: > Thanks Tom, that makes sense. Appreciate your time to explain the context. > > I'll followup with Heroku. Also, I have heard PL/V8 is very hard to build for packagers (because of changes by Google in the way V8 is packaged), which has decreased PL/V8 adoption. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On 26.03.2020 03:50, Bruce Momjian wrote: > On Wed, Mar 25, 2020 at 05:46:27PM +0200, Marius Andreiana wrote: >> Thanks Tom, that makes sense. Appreciate your time to explain the context. >> >> I'll followup with Heroku. > Also, I have heard PL/V8 is very hard to build for packagers (because of > changes by Google in the way V8 is packaged), which has decreased PL/V8 > adoption. True. Btw, Nginx made their own JS implementation https://nginx.org/en/docs/njs/index.html It might be easier in integration than V8.
On Thu, Mar 26, 2020 at 10:07:48AM +0300, Ivan Panchenko wrote: > > On 26.03.2020 03:50, Bruce Momjian wrote: > > On Wed, Mar 25, 2020 at 05:46:27PM +0200, Marius Andreiana wrote: > > > Thanks Tom, that makes sense. Appreciate your time to explain the context. > > > > > > I'll followup with Heroku. > > Also, I have heard PL/V8 is very hard to build for packagers (because of > > changes by Google in the way V8 is packaged), which has decreased PL/V8 > > adoption. > > True. > > Btw, Nginx made their own JS implementation > > https://nginx.org/en/docs/njs/index.html > > It might be easier in integration than V8. Oh, that sounds promising. :-) -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
чт, 26 мар. 2020 г. в 10:08, Ivan E. Panchenko <i.panchenko@postgrespro.ru>: > > > On 26.03.2020 03:50, Bruce Momjian wrote: > > On Wed, Mar 25, 2020 at 05:46:27PM +0200, Marius Andreiana wrote: > >> Thanks Tom, that makes sense. Appreciate your time to explain the context. > >> > >> I'll followup with Heroku. > > Also, I have heard PL/V8 is very hard to build for packagers (because of > > changes by Google in the way V8 is packaged), which has decreased PL/V8 > > adoption. > > True. > > Btw, Nginx made their own JS implementation > > https://nginx.org/en/docs/njs/index.html > > It might be easier in integration than V8. Yet more lightweight JavaScript engine - https://bellard.org/quickjs/ "Small and easily embeddable: just a few C files, no external dependency, 210 KiB of x86 code for a simple hello world program." "Almost complete ES2019 support including modules, asynchronous generators and full Annex B support (legacy web compatibility)."