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