To: "Jeroen T. Vermeulen" <jtv@xs4all.nl>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: libpq notice processors 
In-reply-to: <20040129183731.GI43961@xs4all.nl> 
References: <20040129183731.GI43961@xs4all.nl>
Comments: In-reply-to "Jeroen T. Vermeulen" <jtv@xs4all.nl>
	message dated "Thu, 29 Jan 2004 19:37:31 +0100"
Date: Thu, 29 Jan 2004 14:07:39 -0500
Message-ID: <26188.1075403259@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"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