Sean Chittenden <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings