Show HN: PLJS – JavaScript for Postgres

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.

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.

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.