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. +
