Re: Patch to be verbose about being unable to read ~/.pgpasss...

> > 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.

Bah, this is nuts: I have too many balls in the air at the moment and
need to spend a half minute thinking about things.  My apologies.

In the current form it's not possible to catch unless stderr is going
to a log file or the terminal, which is what I had in mind.  In the
case of Qt or some other GUI, writes to stderr where stderr is closed
doesn't kill the app.

> 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).

Doesn't sound like that's the case any more, though I don't have a
win32 machine to test with.  My understanding is that mingw handles
this correctly, likely same with cygwin.  Native MSVC, however, I have
no clue.

> 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.

If the app can't, and to deal with the case of PasswordFromFile()
being called before the connection is returned to the user, would you
object to adding an optional function to libpq that lets you allocate
a pg_conn and then pass pg_conn to PGconnectdb2()?

conn = PGnewconn();
conn->hostname = "foo";
conn->noticeHooks.noticeProc = myHandler;
/* setup the connection struct manually */
if (PGconnectdb2(conn) == true) {
  /* Connected */
} else {
  /* Not connected */
}

This wouldn't affect existing code and would still allow calling
PGconnectdb() to get a new connection handle.  I'll make the
fnoticeProc introduced above private and have it pass the resulting
buffer to noticeProc.

I maintain that having a security concern in PasswordFromFile() cause
the connection to abort as the default behavior is a bad idea.  It can
be the default with PostgreSQL's CLI utilities that make use of libpq
(would need to add a paranoid flag to the connection), but it
shouldn't be the default.

-sc

--
Sean Chittenden