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@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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