From: | "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl> |
---|---|
To: | pgsql-interfaces(at)postgresql(dot)org |
Subject: | libpq notice processors |
Date: | 2004-01-29 18:37:31 |
Message-ID: | 20040129183731.GI43961@xs4all.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-01-29 19:07:39 | Re: libpq notice processors |
Previous Message | stella DEFO | 2004-01-29 16:09:36 | Demande d'aide sur la connection de postgresql à pgaccess |