Sean Chittenden <[EMAIL PROTECTED]> writes: > Those notices were sent to setderr earlier, they were already broken: > at least now there's a ghost of a chance at the app at picking up > those errors.
The notice in PasswordFromFile is broken, yes, but it is a recent addition; it has not been there long and has no seniority in my mind. And no, there's no "ghost of a chance" for the app to pick it up because PasswordFromFile runs before the app has any opportunity to install a notice hook into the new connection object. >> I didn't hear any strong objection to the idea of treating the >> weak-protection complaint as a hard error (connection failure), so >> we can fix the already-existing problem by doing that. > libpq's a library used by many many applications ... do you envison > calling abort(), exit() or _exit()? No, I envision returning a failed connection. > Seems really broken to halt the > app based on FS permissions. Imagine an ISP web based environment > with PHP using libpq to connect to PostgreSQL and an insecure .pgpass > file. Issuing a warning should be plenty sufficient. There are environments in which attempting to print on stderr leads to a core dump (Windows is or at least used to be that way). Returning a failed connection should not be something the app can't deal with --- if it is, that app has got problems anyway. But insisting that we can print on stderr may well be something it cannot overcome. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend