dynamic groups or how do we port /usr/share/postgresql/install-alternatives

[darix]

please provide guidance how something like /usr/share/postgresql/install-alternatives should be ported.

the script picks up all the binaries for a certain version and installs them as a dynamic group.
the dynamic part comes from the fact that any PG extension which provides binaries as well, will also be hooked up as a part of the group created by the script.

IMHO it is a really helpful way to have them switch in a group with the main binary.

[rma-x]

Dynamic also comes through the fact that the set of binaries that come with the PostgreSQL core packages sometimes changes from one major version to another.

[darix]

well not to mention we would also lose the /usr/lib/postgresql symlink when migrating away from update-alternative.

[AdamMajer]

By definition, these things should be "dynamic", or as defined in the config files. So if you have

group=exec1,exec2,exec3

and in another config

group=exec2,exec3

Then I would expect that exec1 is not switched if it doesn't exist in another version.

If a version is unavailable, it will pick another available one with highest priority. But group is only taken into account when switching priorities and is independent otherwise. So if things do not exist, it's probably not really important that they refer to different version?

Are there any examples where this will result in undesirable behaviour?

[darix]

yeah if we switch the whole group to pg 18. all tools should switch and not some stay on 17.

depending on the tool ( e.g. pg_repack ) ... it might not be compatible with the new DB internal formats and then in worst case break things.

[AdamMajer]

I think the risk here is if things don't exist in another version, then they will not switch but stay as-is. But this may require some experimentation what happens. But then you'd have a tool from higher version that doesn't exist in older version.

Normally, when you install new version, you'd be automatically on the new version (higher version). If you switch back to older, you have some override file created as consequence of the "switch". If you switch back to default, then the override is just removed and you are back to highest priority again.

[darix]

the current solution handles this just fine

[rma-x]

It can be both ways as tools can get added or removed in a newer version compared to the older one, and additionally we have some of the tools spread over several optional (sub)packages. But everything that belongs to one PostgreSQL version should get active when that version gets activated and nothing belonging to a different version should be active at the same time.

I think the risk here is if things don't exist in another version, then they will not switch but stay as-is.

AFAIU with that the result of switching to a different version depends on the version that was selected before (or even longer history) which I don't think is a desirable behavior.