Interesting. This is now the second DB next to Oracle[1] that can do JS (that I know of). pgSQL and PL/SQL of course still stay relevant but in the Oracle spehere the argument is that you can reuse existing code from NPM. Like this blog post [2] describes how to run an GraphQL endpoint from within the DB.
What are the advantages to pljs over plv8? I thought the context creation would have been the big one, but it doesn't appear so in the current benchmarks.
How did the project weigh the intermittent updates of bellard quickjs and the community fork quickjs-ng?
I too was surprised about the slower startup and am planning on spending a lot of time in the quickjs repo to try to improve it. Thankfully most use cases use a connection pooler, which removes startup costs from the equation, leaving conversion speed much more important. I was able to speed up conversion of jsonb by writing a custom conversion from jsonb to quickjs and back, but feel there is still a lot of room for improvements.
As for quickjs vs quickjs-ng: ng is a fantastic project and I’m really hoping it pulls an egcs and ends up canonical, but when this project was started, it did not exist, so quickjs was chosen as the starting point. As for why it has not been adopted yet by this project, it comes down to a few things that helped make the decision:
* quickjs is still having releases
* as learned from plv8, when there are constant changes it becomes much harder to maintain, so a steady target is easier to deal with (this is constantly being evaluated)
* the build system change from make to cmake adds friction to Postgres embedding, I already have to patch quickjs, and would need more complicated patches for quickjs-ng. I have a good working relationship with Ben Noordhuis, but it’s still a source of friction that isn’t needed now.
As things change, everything will be re-evaluated, but for now quickjs itself works great.
What would be the typical use-case? Light data transformation?
Is there a significant advantage over Rust-based embedded Postgres language like https://github.com/tcdi/plrust which is compiled and a bit more type-safe?
A lot of logic just becomes easier with javascript. If you have complex-ish trigger logic, or a procedure etc - doing these in pl/pgsql is just hard if not intracatable. Also allows up reuse of a lot of code that people have built with npm - even if not directly with require(), it becomes possible to bundle compiled binary.
I used this for storing patches of data (to save space, compression is a pain in Postgres) and applying runtime to show full version etc. It's fun.
Interesting. This is now the second DB next to Oracle[1] that can do JS (that I know of). pgSQL and PL/SQL of course still stay relevant but in the Oracle spehere the argument is that you can reuse existing code from NPM. Like this blog post [2] describes how to run an GraphQL endpoint from within the DB.
[1] https://docs.oracle.com/en/database/oracle/oracle-database/2... [2] https://blogs.oracle.com/developers/post/creating-a-graphql-...
PLV8 (the predecessor to this project) was released in June of 2012. It provided JavaScript as a trusted language extension to Postgres 9.2.
PLJS is a newer generation.
What are the advantages to pljs over plv8? I thought the context creation would have been the big one, but it doesn't appear so in the current benchmarks.
How did the project weigh the intermittent updates of bellard quickjs and the community fork quickjs-ng?
I too was surprised about the slower startup and am planning on spending a lot of time in the quickjs repo to try to improve it. Thankfully most use cases use a connection pooler, which removes startup costs from the equation, leaving conversion speed much more important. I was able to speed up conversion of jsonb by writing a custom conversion from jsonb to quickjs and back, but feel there is still a lot of room for improvements.
As for quickjs vs quickjs-ng: ng is a fantastic project and I’m really hoping it pulls an egcs and ends up canonical, but when this project was started, it did not exist, so quickjs was chosen as the starting point. As for why it has not been adopted yet by this project, it comes down to a few things that helped make the decision:
As things change, everything will be re-evaluated, but for now quickjs itself works great.Amazing.. Would be nice to have something like that for Redis to replace Lua
No npm support is a huge limitation.
What would be the typical use-case? Light data transformation?
Is there a significant advantage over Rust-based embedded Postgres language like https://github.com/tcdi/plrust which is compiled and a bit more type-safe?
A lot of logic just becomes easier with javascript. If you have complex-ish trigger logic, or a procedure etc - doing these in pl/pgsql is just hard if not intracatable. Also allows up reuse of a lot of code that people have built with npm - even if not directly with require(), it becomes possible to bundle compiled binary.
I used this for storing patches of data (to save space, compression is a pain in Postgres) and applying runtime to show full version etc. It's fun.