Generic Extension Strategy

[amerryma]

Lets say I have a few extensions that the pglite repo doesn't know about, will the expected workflow be to fork pglite, add those extensions as part of the build process, then build it myself?

I have a bunch of extensions I'd like to see used in my pglite db, but doesn't seem like those should be part of the default offering.

[samwillis]

Hey, yes we have a few options for doing generic extensions and a few problems to solve to enable them.

So far to enable pl/pgsql we had to statically link the extension to the build. It should be possible to dynamically link extensions but I believe #56 is what cased issues when I tried to enable this.

One thing to consider is that for the main binary to support arbitrary dynamically loaded extensions we would have to disable any dead code elimination, this will make the build larger. I suspect we will have to have a special WASM binary that enables loadable extensions and others that have a few key ones statically likened, and a minimal build too.

[amerryma]

Ok, great, I'll keep an eye on this space. And just FYI the extensions would be:

plpgsql_check
pg_net
pg_graphql

[yihong0618]

Ok, great, I'll keep an eye on this space. And just FYI the extensions would be:

plpgsql_check pg_net pg_graphql

these extensions are hander cause then use pgrx develop....

[mingfang]

My vote is for
AGE https://github.com/apache/age
and
Search https://github.com/paradedb/paradedb

[lastmjs]

Will the Wasm component model be the nicest long-term solution here? My understanding is that this allows some form of dynamic linking. Each extension might be its own Wasm binary that can be dynamically loaded plug-and-play style for the developer.

[samwillis]

@lastmjs yes ideally we will have dynamic loading of extensions. There is some complexity around this as it will likely add a little overhead.

The current intention is that core extension such as pl/pgsql will be staticky linked (we have this one already working with static linking)