Sean Chittenden <sean@chittenden.org> 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
