Re: pg_upgrade and PGPORT

Peter Eisentraut wrote:
> pg_upgrade is a bit schizophrenic concerning the PGPORT environment
> variable. On the one hand, there is this code in option.c that wants to
> make use of it:
>
> old_cluster.port = getenv("PGPORT") ? atoi(getenv("PGPORT")) : DEF_PGPORT;
> new_cluster.port = getenv("PGPORT") ? atoi(getenv("PGPORT")) : DEF_PGPORT;
>
> On the other hand, check.c will reject a set PGPORT because it's a libpq
> environment variable. Should we make an exception for PGPORT, like we
> did for PGCLIENTENCODING?

Wow, good question. Passing stuff in via libpq is certainly complex.

I ran a test and it looks like the command-line flag overrides the
PGPORT environment variable:

$ export PGPORT=3333
$ psql test
psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.3333"?
$ psql -p 5432 test
psql (9.1beta1)
Type "help" for help.

test=>

I assume it is just like PGCLIENTENCODING. PGCLIENTENCODING was easier
to ignore because we need it for error messages.

Are there other cases we should allow too?

A larger question is whether we should just disable all the checks for
environment variables. The C comment says:

* check_for_libpq_envvars()
*
* tests whether any libpq environment variables are set.
* Since pg_upgrade connects to both the old and the new server,
* it is potentially dangerous to have any of these set.
*
* If any are found, will log them and cancel.

I am not sure what to do.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +