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

Hi All,

I am developing the TimescaleDB extension for postgres (https://github.com/timescale/timescaledb) and have some questions about versioning. First of all, I have to say that the versioning system on the sql side is wonderful. It's really simple to write migrations etc.

However when thinking through the implications of having a database cluster with databases having different extension versions installed, it was not apparently clear to me how to synchronize the installed extension version with a shared library version. For example, if I have timescaledb version 0.1.0 in one db and version 0.2.0 in another db, I'd like for timescaledb-0.1.0.so and  timescaledb-0.2.0.so to be used, respectively. (I want to avoid having to keep backwards-compatibility for all functions in future shared-libraries). In our case, this is further complicated by the fact that we need to preload the shared library since we are accessing the planner hooks etc. Below, I'll describe some solutions I have been thinking about, but wanted to hear if anyone else on this list has already solved this problem and has some insight. It is also quite possible I am missing something. 

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.

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.