On Thu, Feb 9, 2017 at 9:40 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Thu, Feb 9, 2017 at 8:17 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: >> +1. Sounds sensible thing to do. > > Hm. It seems to me that PGPASSFILE still needs to be treated as an > exception because it is set to $HOME/.pgpass without any value set in > PQconninfoOption->compiled and it depends on the environment. Similar > rules apply to fallback_application_name, dbname and replication as > well, so they would need to be kept as checked on an individual basis. > > Now it is true that pg_basebackup -R enforces the value set for a > parameter in the created string if its environment variable is set. > Bypassing those values would potentially break applications that rely > on the existing behavior.
Hmm, I didn't think about environment variables. > In short, I'd like to think that we should just filter out those two > parameters by name and call it a day. Or introduce an idea of value > set for the environment by adding some kind of tracking flag in > PQconninfoOption? Though I am not sure that it is worth complicating > libpq to just generate recovery.conf in pg_basebackup. Yeah, I'm not sure what the best solution is. I just thought it was strange. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
