Is it possible to dynamically load an extension?

[barbalex]

I am using electric-sql to build a local-first app.
electric-sql uses wa-sqlite for local persistence.

My app uses UUID's in version 7. For rows created client side I can use a js library to create the uuids.
I need a solution to create v7 uuid's when creating new rows inside triggers though.

I found this extension for sqlite.

How can I .load uuidv7.so when using wa-sqlite?

Maybe the answer is to build locally and integrate that build into wa-sqlite/electric-sql?
Or is there a way that uuidv7.so could be dynamically loaded?

I am grateful for any insights.

[tantaman]

From my experience it isn't generally possible given some design constraints of the current WASM module loading system and emscripten's dlopen.

If uuidv7 doesn't depend on any functions not exported by wa-sqlite then it can work using dlopen. I'd recommend statically linking it though.

They explained that one major limitation with dlopen() is that the loading module must provide any and all exported symbols for the dll. If a module only relies on sqlite3 APIs which have already been exported, it "should work," but as soon as they rely on anything else, whether it be non-exports sqlite3 APIs or system-level APIs which are not linked in to/exported from sqlite3.wasm, it won't work.

https://sqlite.org/forum/forumpost/adac7712d623f8b1

[rhashimoto]

@tantaman knows 100% more (literally) about dynamic loading WASM than I do.

Perhaps you can use create_function() to provide a way to call your JavaScript UUID implementation from your trigger? This will only work if UUID creation is synchronous (except for an ugly unsupported hack).

[barbalex]

Yeah, create_function makes sense if it is possible to build a uuid v7 inside a function. Which it should be. But that doesn't mean that I am capable of achieving it 😅

[barbalex]

I found this for postgresql: https://gist.github.com/kjmph/5bd772b2c2df145aa645b837da7eca74
But it builds on postgre's gen_random_uuid().

[AntonOfTheWoods]

@barbalex pglite support for electric is going to drop any day now (this week or next given the commits that are piling up!) and that is going to make a lot of things a heap easier. Particularly with electric that basically wanted to do local-first postgres from the get go, I would say wait for that unless you have insane local performance requirements.