Re: [HACKERS] Syncing sql extension versions with shared library versions

Issue 1: Preloading the right shared library.
When preloading libraries (either via local_preload_libraries, or session_preload_libraries, shared_preload_libraries), it would be nice to preload the shared_library according to it's version. But, I looked through the code and found no logic for adding version numbers to shared library names.

You can't do that for shared_preload_libraries, because at shared_preload_libraries time we don't have access to the DB and can't look up the installed extension version(s). There might be different ones in different DBs too.

Yeah shared_preload_libraries is a special case I guess. Something like that could work with  local_preload_libraries or session_preload_libraries right?

Solution 1: Set session_preload_libraries on the database via ALTER DATABASE SET. This can be done in the sql and the sql version-migration scripts can change this value as you change extensions versions. I think this would work, but it seems very hack-ish and less-than-ideal.

Won't work for some hooks, right?

I've faced this issue with pglogical and BDR. If the user tries to update the extension before a new enough .so is loaded we ERROR due to failure to load missing C functions.

This is a good point. Thanks for bringing it to my attention. I guess if the CREATE FUNCTION call contained the name of the new .so then it would force a load, right? But that means you need to be safe with regard to having both .so file loaded at once (not sure that's possible). I think this is the biggest unknown in terms of whether a stub-loader /can/ work.

 

If the .so is updated first the old extension function definitions can fail at runtime if funcs are removed or change signature, but won't fail at startup or load.

So we let the C extension detect when it's newer than the loaded SQL ext during its startup and run an ALTER EXTENSION to update it.

Yeah that's very similar to what we do now. It doesn't work for multiple dbs having different extension versions, though (at least for us).