Container fails to run commands

[chrkr]

The container fails to run any command given with docker run (for any command other than the default postgres command):

$ docker run --rm pgautoupgrade/pgautoupgrade:18.4-debian ls
************************************
PostgreSQL data directory: /var/lib/postgresql/18/docker
************************************
/usr/local/bin/postgres-docker-entrypoint.sh: line 415: [: -eq: unary operator expected
/usr/local/bin/postgres-docker-entrypoint.sh: line 429: [: : integer expression expected
/usr/local/bin/postgres-docker-entrypoint.sh: line 432: [: : integer expression expected
/usr/local/bin/postgres-docker-entrypoint.sh: line 435: [: : integer expression expected
/usr/local/bin/postgres-docker-entrypoint.sh: line 438: [: : integer expression expected
/usr/local/bin/postgres-docker-entrypoint.sh: line 441: [: : integer expression expected
****************************************************************************
Unrecognised version of PostgreSQL database files found, aborting completely
****************************************************************************

It seems to mostly come from some variables not being set at all earlier in the script when the command is not postgres.

This issue prevents the container from being used as a full drop-in replacement for the regular postgres container.

[andyundso]

Sorry for the late response @chrkr.

What do you actually want to run with the pgautoupgrade container that is not postgres? In theory we could hop over the entire pgautoupgrade process if the command is not postgres, but I am not sure about the usefulness of that.

[chrkr]

Specifically I was using pg_restore, but this applies to any command. An important use case would be where this container is used in a stack where it is the only one with the postgres cli tools installed. The normal postgres container handles this just fine. Also it seems that the script does consider whether the command is postgres or not, and skips a lot of things, but some non-skipped part later on depends on variables being set by the skipped part.

Note I use this as a full postgres replacement not just for one-off upgrades.

[andyundso]

@chrkr ah that makes sense. I see what I can do in the near future.