> We expect the .so's own minor version number to suffice for that,
> but I realize that that might not be the most user-friendly answer.
One of my desires is that the on-disk .so's filename be associated with the pg_extension entry and not Each. Individual. Function. There's a few extensions that like to version the on-disk .so's filename which means a CREATE OR REPLACE for every function on every extension version bump. That forces an upgrade script even if the schema didn't technically change and also creates the need for bespoke tooling around extension.sql and upgrade.sql scripts.
I understand the potential pain with this (though I suppose MODULE_PATHNAME can somewhat alleviate it). However, I'd like to highlight the fact that, besides the fact that control files contain a reference to a .so file, there's very little in the way of actual dependency of the extension mechanism on shared libraries, as that part relies on functions being able to use C language for their implementation. Nothing I am aware of would stop you from having multiple .so files in a given extension (for one reason or another reason), and I think that's actually a great design, incidentally or not. This does allow for a great deal of flexibility and an escape hatch for when the straightforward case doesn't work [1]
If the extension subsystem wasn't replacing MODULE_PATHNAME, I don't think there would be a reason for having `module_pathname` in the control file. It doesn't preload the file or call anything from it. It's what `create function` in the scripts will do. And that's actually great.
I am referencing this not because I don't think you know this but to try and capture the higher-level picture here.
This doesn't mean we shouldn't improve the UX/DX of one of the common and straightforward cases (having a single .so file with no other complications) where possible.
--