The update strategy has nothing to do with the on-delete behavior. <...> deleting the pod will have no effect on the data since the volume is tied to the claim rather than the pod itself

I totally agree with coderanger, you should consider the data from Postgres independently. Usually, people create a separate volume (with the PVC) mounted on /usr/local/pgsql/data. When you delete/re-create a new Postgres pod, you still claim the same volume to mount it back without affecting your data.

The update strategy has nothing to do with the on-delete behavior. That's used when a change to the pod template triggers an update. Basically does it nuke the old ReplicaSet all at once or gradually scale things up/down. You almost always way RollingUpdate unless you are working with software that requires all nodes be on exactly the same version and understand this will cause downtime on any change.

As for the Retain volume mode, this is mostly a safety net for admins. Assuming you used a PVC, deleting the pod will have no effect on the data since the volume is tied to the claim rather than the pod itself (obviously things will go down while the pod restarts but that's unrelated). If you delete the PVC, a Retain volume will be kept on the backend but if you wanted to do anything with it you would have to go in and do it manually. It's like a "oops" protection, requires two steps to actually delete the data.