libpq notice processors
От | Jeroen T. Vermeulen |
---|---|
Тема | libpq notice processors |
Дата | |
Msg-id | 20040129183731.GI43961@xs4all.nl обсуждение исходный текст |
Ответы |
Re: libpq notice processors
|
Список | pgsql-interfaces |
Is it actually required that a message passed to the notice processor end in a newline? For libpqxx it would be highly convenient if this were optional from the caller's point of view. The library itself calls the same handler sometimes. Adding the newline to an error or warning message is not only inefficient, it also introduces certain risks of failure. That's just what you don't want to have when handling an error in the first place--error handling clauses are usually the worst-tested corners of the program. Simply making the newline optional may be inconvenient for the notice processor, e.g. if it's something like fprintf(stderr,"%s",msg); (and we want to give the user maximum convenience to reduce bugs) so here's one relatively easy way to solve the problem: * The message passed to the handler "ought to" end in newline, but it doesn't always. * If the trailing newline is missing, it will be written by the next call to the notice processor. * If the original message missed its trailing newline, the next message will contain only the missing newline. Now, whenever it is inconvenient to tack a trailing newline to a message, libpqxx could call the notice processor twice--once with the message text and once with the newline. A printf-style notice processor would continue simply to print out what it's given, as before. A typical GUI notice processor, which might want to pop up a dialog for each message, can display the message regardless of trailing newline, provided it ignores messages consisting only of "\n". Jeroen
В списке pgsql-interfaces по дате отправления: