From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Andreas Pflug <pgadmin(at)pse-consulting(dot)de>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PGPASSWORD and client tools |
Date: | 2004-08-19 02:07:20 |
Message-ID: | 7098.1092881240@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> How about an environment variable that points to a .pgpass type file.
You can do that today: point $HOME at some temp directory or other.
AFAIR pg_dump doesn't make any other use of $HOME ...
> Or we could even play games with PGPASSWORD - if it names an existing file
> that satisfies the .pgpass criteria then it will be taken as the
> location of the .pgpass file instead of $HOME/.pgpass - otherwise its
> value will be considered to be the password itself.
Gaack... if you want a separate variable, we can talk about that, but
let's not overload PGPASSWORD like that. Consider even just the
implications of whether libpq error messages should echo back the
"filename" ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-08-19 02:12:53 | Re: Open items |
Previous Message | Christopher Kings-Lynne | 2004-08-19 02:03:57 | Re: PGPASSWORD and client tools |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2004-08-19 02:24:13 | Re: PGPASSWORD and client tools |
Previous Message | Christopher Kings-Lynne | 2004-08-19 02:03:57 | Re: PGPASSWORD and client tools |