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 testpsql: could not connect to server: No such file or directory        Is the server
runninglocally and accepting        connections on Unix domain socket "/tmp/.s.PGSQL.3333"?$ psql -p 5432 testpsql
(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
theold 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@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +