Re: [PATCH] Support % wildcard in extension upgrade filenames

On Mon, May 1, 2023 at 11:05 PM Eric Ridge <eebbrr(at)gmail(dot)com> wrote:

>
> > 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.

[1]
https://yrashk.com/blog/2023/04/10/avoiding-postgres-extensions-limitations/
--
https://omnigr.es
Yurii.