Sean Chittenden <sean@chittenden.org> writes:
> All regression tests pass with this case and no ABI or source
> incompatabilities are introduced.
You're still playing extremely fast and loose with that claim of "no
incompatibilities introduced". This may not *directly* break an
application that uses PQsetNoticeProcessor, but it breaks the purpose
that the app is using PQsetNoticeProcessor for, namely to intercept
notices. If it doesn't also override the fnoticeProc then it hasn't
intercepted all the notices.
What I was envisioning was a simple little subroutine that takes a
format string and some args, formats into a work buffer, and then passes
the formatted string to the existing notice hook. Essentially, moving
the five lines you're unhappy about into a common subroutine. This
gets the job done without *any* modification of the application API.
A bigger problem with the whole approach is that there's no way for
the application to install a notice processor before PasswordFromFile
is invoked, because that occurs during PQconnectdb. So any notices
emitted by same will necessarily fall into the lap of the default
notice processor.
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. As
for the issue of whether to complain about a file that exists but
isn't readable, Peter exhibited lots of precedent for not doing so.
I'm inclined to think we should drop that part.
regards, tom lane