Standby replication authorization user and slot settings can't be in `postgresql.acid.zalan.do` CRD

Please, answer some short questions which should help us to understand your problem / question better?

• Which image of the operator are you using? ghcr.io/zalando/postgres-operator:v1.12.2
• Where do you run it - cloud or metal? Kubernetes or OpenShift? Bare Metal K8s
• Are you running Postgres Operator in production? no
• Type of issue? feature request

Hi, I checked all documentation of Postgres Operator I can't understand why standby user is set under Postgres Operator globally at .Values.configUsers.replication_username which will create operatorconfigurations.acid.zalan.do CRD.

Trying to override PGREPLICA_USER fails, as it controlled by operator and it totally ignores this env, which is expected, okay.

My use case is: I have couple of Postgres clusters outside of my K8s cluster, that I want to replicate physically to mine infra (cascading replication), each must have own replica user, aka: svc-{team}-{cluster}-replication, while team for me will be same, cluster name of course is changing. Plus I want to deploy normal (not standby) Postgres deployments.

Such situation mean that for each standby cluster I need to have dedicated operator deployment, and for my own non-standby Posgreses I need have another deployment of operator. All this operators must be limited to own controller-ID and each postgres manifest should clearly say which via annotation acid.zalan.do/controller by whom they are controlled, but all this overkill is just to set standby user...

I think Operator need to allow setting standby credentials (and slot) in CRD and in this case 1 operator will be enough to rule everything:

apiVersion: acid.zalan.do/v1
kind: postgresql
spec:
  standby:
    standby_host: my-main-cluster
    standby_port: "5432"
    standby_auth_secret_name: my-secret
    standby_user_secret_key: user # by default
    standby_password_secret_key: password # by default
    standby_slot: my-replica-slot

Same things are applicable to super_username & pooler stuff

#2720 rewind stuff not aviable not at all.

Start by reviewing the postgresql.acid.zalan.do and operatorconfigurations.acid.zalan.do CRDs, especially the proposed standby fields and the existing global replication_username setting. Confirm how standby credentials and slots are configured today; done means one operator can manage standby and normal clusters with per-Postgres standby credentials and slots, without separate operator deployments.