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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers