Constantine Peresypkin

Workaround, create the following in the start proc: ``` const callArgs = Symbol() const plv8[callArgs] = [''] plv8.call = (name, ...args) => { let vars = plv8[callArgs][args.length] if (vars ==...

It errs on the safe side though. Which is good. Anyway workaround above has one advantage: you can run non-plv8 functions too. So maybe it's good enough.

permissions are easy, if you use the database itself to store these modules, i.e. tables actually it's not that hard to implement some sort of a centralized module repo and...

But isn't it still just an SPI interface that will check all the permissions at the beginning of query execution?

> ```js > // import from a database table > import foo from plv8.execute('select content from some.table where id=12345') > ``` That's fun and all but it cannot resolve underlying...

> I'm running into needing this again, this time trying to do some headless chrome / puppeteer stuff from plv8. Talk about a perfect screen-scraping and automation foundation, plv8 +...

Ok. I'm going to do it. Essentially module support requires two big features: 1. FileSystem. 2. Import resolution. Implementing FS is pretty easy, in fact I'm almost ready with it....

@JerrySievert got some code today. But it's problematic. Spec for ESM states that top level `await` and `async` dynamic load must be supported... And I'm totally not in the mood...

@JerrySievert I suppose the following is a good API idea https://nodejs.org/api/esm.html#esm_experimental_loaders But these are not final. Probably will postpone the `import` implementation till the loader spec matures. Although I think...

Wrote some more code and I fail to understand how it can be implemented in an embedded context at all. I.e. when people created the `module` spec they did not...