Oliver Jowett wrote:
Tom Lane wrote:
Oliver Jowett <[EMAIL PROTECTED]> writes:
Assuming that you can't tweak .pgpass (for example, you're just propagating a password you interactively got from the user), what's the recommended way to provide the password?
In the connection string given to PQconnectdb (or equivalent).
If you're a shell script calling psql / pg_dump / etc, how do you do this?
-O
Exactly. Also, when a script is executed from a binary and the password is passed in as a parameter and PGPASSWORD is set inside the script, it is local to the script.
I understand that on some operating systems environmental variables may be seen by anyone on the system. In every Linux, UNIX, and even Win 2k with batch files, the variable can be local and even if exported can be unset by the script before it exits.
Unless the utilities like psql and pg_dump are changed to accept a password as a command line option, I don't think PGPASSWORD should go away. It is too useful for those that know how to properly use and destroy environmental variables. The documentation points out that the use of PGPASSWORD can be dangerous on some systems. I think it is up to the administrators of those systems to make that choice to use or not use rather than have a very useful mechanism removed with no viable alternative.
Again, the advantage is I can let users with no database login have controlled access to database data and utilities without them actually having a user name and password to the database. Without the ability to use PGPASSWORD, I have to expose the password in a .pgpass file for every user I want to allow access. I think that is far more insecure.
John Griffiths
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
