Thread: libpq notice processors

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 

"Jeroen T. Vermeulen" <jtv@xs4all.nl> writes:
> 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.

You're proposing to push the inconvenience out of the library and onto
the shoulders of application authors, who will now have to deal with
inconsistent message formatting in their notice-catcher hook routines.
I think that would be sloppy library design.

I'm not that thrilled with the decision to include newlines in the
standard format --- if I'd been around at the beginning I'd have said
that what goes to the hook should never include a trailing newline.
But changing that API detail now would incur far more pain than it's
worth, IMHO.

>  * If the trailing newline is missing, it will be written by the next
>    call to the notice processor.

Splitting one logical call into two seems entirely unacceptable to me.
As an example, consider a GUI whose hook catcher inserts each notice
into a one-line window, replacing what was there before.  This change
will *break* that app, since it'll wipe out the useful text with an
empty message.  Sure, it's fixable by ignoring "empty" messages, but
the code involved is not under our control and I don't think we get
to demand changes in apps simply to avoid some inconvenience in our
library.

If we were going to demand a change in notice processors, I'd think the
better approach is just to state that the notice text may or may not end
in a newline, and the hook routine should strip or add one as it wishes.
This is less of a change conceptually than splitting a single logical
message across multiple calls.  But I disagree with changing the API at
all.
        regards, tom lane

On Thu, Jan 29, 2004 at 02:07:39PM -0500, Tom Lane wrote:
> 
> If we were going to demand a change in notice processors, I'd think the
> better approach is just to state that the notice text may or may not end
> in a newline, and the hook routine should strip or add one as it wishes.
> This is less of a change conceptually than splitting a single logical
> message across multiple calls.  But I disagree with changing the API at
> all.

Fair enough.

Hello:

I want to display graphics from my postgresql database, but I must 
choose the proper tool first.
Which one is more suitable?:
perl?
php?
pg_autodoc?
another one?

Thank you in advance,
Carlos