> > -typedef void (*PQnoticeProcessor) (void *arg, const char *message);
> > +typedef void (*PQnoticeProcessor) (void *arg, const char *message, ...);
>
> This isn't going to happen. It would break every existing
> application that uses a notice processor, since they are not
> expecting to have to treat the message as a format string (quite
> aside from your unportable assumption that this doesn't change the
> function's ABI).
Um, I said it would change the ABI and I said as much in my previous
post. When would be a better time to have this go in? The major
version number of libpq is going to get bumped because of the various
changes that have gone in (isn't it?)... all the same, this shouldn't
break applications that are recompiled with libpq provided their error
message doesn't contain a format string: normal strings will work as
expected, it is code compatible provided people aren't using any %
escape strings in their error messages (if there aren't any format
strings, there won't be any need to modify the program), and it should
be easier for people to write error messages with some kind of context
(using vfprintf() is much easier than sprintf()'ing a message into a
buffer and passing the buffer to the handler - 1 LOC vs at the minimum
5). In the release notes, ask people to use -Wformat if they're
trying to lint for old code. The risk seems low to me. *shrug*
-sc
--
Sean Chittenden
