Update docker compose to support postgreql 18+

[samwiseg0]

Description

With the updated postgresql (v18) docker image. The container failed to start. Citing this issue. docker-library/postgres#37

The docker compose file has been updated to reflect the new path.

Demo

N/A

Checklist

• I have read CONTRIBUTING.md in its entirety
• I have performed a self-review of my own code
• I have added unit tests to cover my changes
• The last commit successfully passed pre-commit checks
• Any AI code was thoroughly reviewed by me

[krokosik]

Could you verify it works with Postgres 16+ as well?

[samwiseg0]

Yes this does work with v16. I tested with the postgres:16.10-bookworm image.

Although I think this maybe a "breaking change". When upgrading from 16->18 the data structure changed so users upgrading will need to do a migration with the steps outlined in the docker documentation provided prior to the image upgrade. https://github.com/oss-apps/split-pro/tree/main/docker#migrating-instance

On another note it maybe worth pinning docker compose to a major version. Maybe adding a tag for the latest major version? such as ossapps/postgres:18.

[krokosik]

Yes, the pin is a good idea. Regarding upgrades AFAIK it is on user side, considering they don't pull the updated compose file or force-pull an update image. Unless, they do it intentionally of course.

Considering that v18 was just released, I would prefer to pin the version to v17 instead. We don't use any features from v18 and 17 had much more time to stabilize with minor patches.

[samwiseg0]

The latest image from docker is v18 so some changes will need to be made there. If someone were to run docker compose today it will be broken since latest is v18

Would you like me to update the docker compose file with the 17 tag?

Obviously that tag will need to be added to the docker image.

[krokosik]

For new users I agree. I meant that existing users should be safe. I would update the tag to 17.10-trixie since we don't have 17 in our tags.

[samwiseg0]

Sure I can do that but I would suggest the tag be created since that way the docker compose file will only need to be updated per major version.

For example, If 17.10. is updated to lets say 17.30 you would not have to update the compose file since it would be part of the major version 17 tag.

[krokosik]

Good idea, I would be happy to accept a PR with appropriate scripts for that