Password issue revisited

Fellow PostgreSQL fans,
Last year there was a pretty lengthy discussion (Tom Lane offered a lot of insights) on this list about deprecating the PGPASSWORD environmental variable. I understand the security issues here very well. However, up through version 8.1, it has been easy to use pg_dump and pg_restore from other applications (PHP, Java, etc.) by capturing the Password prompt on stderr and sending the password on stdin. No more. Now, this interaction is done on low-level I/O data streams. Also, it appears from the documentation that the PGPASSFILE environmental variable has been deprecated for pg_dump and pg_restore. It appears the only way these utilities can run from a script or other application is to ensure that the user specified in the command-line has a .pgpass file.

I would like to ask that we return to outputting the Password prompt on stderr and accepting password input on stdin. Here are the reasons.

1. I don't see that this would pose a major security risk. In fact, in applications where the user enters the password for each session, the password need never be saved to disk, which seems a definite security advantage. Some folks have noted that .pgpass is a plain text file, hence it could be vulnerable.
2. PostgreSQL has a tradition of respecting generally accepted standards. The use of high-level input/output is a standard for many programming languages.
3. PostgreSQL has a tradition of cross-platform compatibility. Use of high-level input/output allows cross-platform applications (e.g., Java) to interact with PostgreSQL in a straightforward and standardized fashion.
4. Low level input/output is considerably more difficult and less reliable for other applications to access and work with.

Thanks for considering this matter.

Michael Schmidt