Feature Request: enable 2 digit version numbers

[mzwettler2]

Overview

Related images are pretty cool. Actually, there are only 1 digit version numbers allowed for postgres images. No version numbers are allowed for all other images. It would be cool to enable 2 digit version numbers for all images.

Use Case

Our customers require to control which minor version to use and when to change this minor version.

At this time this can only be controlled by using all qualified image* flags. The location of the images become somewhat hardcoded and unflexible this way. The new "paused" flag with PGO 5.2 will pause any deployment to the postgrescluster and can only be used for a very short time.

Enabling 2 digit version numbers would give our customers full control which minor version they use and when it is changed.

Desired Behavior

postgresVersion: 15.1
pgbackrestVersion: 2.41
pgadminVersion: 4.30

Environment

Tell us about your environment:

Please provide the following details:

Platform: Anthos
Platform Version: 1.10 (afaik)
PGO Image Tag: postgres-operator:ubi8-5.3.0-0
Postgres Version: 14
Storage: vm ware csi
Number of Postgres clusters: several

[andrewlecuyer]

@mzwettler2 thanks for reaching out!

To ensure I am following, are your users specifically looking to better control rollouts of minor PG version updates? For instance, by also providing a minor version number field in the PostgresCluster spec alongside postgresVersion, are you looking to give users the ability to control exactly when a specific patch (ideally the latest patch) is applied (and therefore rolled out to their cluster).

I therefore assume this is more a matter of controlling rollouts of new minor PG versions, rather than simply providing a user with a way of provisioning older/non-patched releases of PG. However, if there is anything that I missed, please let me know.

Thanks!

[mzwettler2]

@andrewlecuyer

Exactly. Our customers want to test the updated environment before they use it in production. Since we have multiple customers on each k8s cluster, we cannot control the rollout at the k8s cluster level. Therefore, we would like to give the customers the possibility to control the patching themselves.

[mzwettler2]

any news?