One other point here: I realized while testing my patch that it's actually
impossible to provoke the failure mode Christoph is unhappy about in psql.
You can only see it in an application that uses PQsetdb/PQsetdbLogin,
which of course psql doesn't anymore. The reason is that in the PQconnect
family of functions, conninfo_add_defaults() is only applied after
filling in all available caller-supplied parameters, so if the user has
in one way or another specified the role name to use, we never invoke
pg_fe_getauthname() at all. It's only called if we have to use the
default role name, and in that context of course a hard failure is
appropriate. But in the PQsetdbLogin code path, we do pg_fe_getauthname
first and then overwrite (some) values from the parameters, so a failure
during conninfo_add_defaults() is premature.
This is a tad disturbing, because we are not using and therefore not
testing PQsetdb/PQsetdbLogin anywhere, which means that any failure modes
that path acquires that don't exist in the PQconnect code path are
guaranteed to go undetected in our testing. Now, I rather doubt that
we'd have found the problem with doesn't-handle-lack-of-/etc/passwd-well
even if we had been testing that code path, but we certainly won't find
problems in paths we don't test.
Not entirely sure what to do about this, but I predict this won't be
the last complaint unless we find some way to improve test coverage
in this area. Or perhaps we could turn PQsetdbLogin into a ***very***
thin wrapper around PQconnectdbParams?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
