Re: Patch to be verbose about being unable to read ~/.pgpasss...
От | Sean Chittenden |
---|---|
Тема | Re: Patch to be verbose about being unable to read ~/.pgpasss... |
Дата | |
Msg-id | 20030622154937.GB47307@perrin.int.nxad.com обсуждение исходный текст |
Ответ на | Re: Patch to be verbose about being unable to read ~/.pgpasss... (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Patch to be verbose about being unable to read ~/.pgpasss...
|
Список | pgsql-patches |
> > -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
В списке pgsql-patches по дате отправления: