To: Peter Eisentraut <peter_e@gmx.net>
Cc: pgsql-interfaces@postgreSQL.org, pgsql-hackers@postgreSQL.org
Subject: Re: Some quick notes about extending libpq for new protocol 
In-reply-to: <Pine.LNX.4.44.0306161602130.2751-100000@peter.localdomain> 
References: <Pine.LNX.4.44.0306161602130.2751-100000@peter.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
	message dated "Mon, 16 Jun 2003 16:51:16 +0200"
Date: Mon, 16 Jun 2003 11:13:42 -0400
Message-ID: <3173.1055776422@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <peter_e@gmx.net> writes:
> In the old protocol there used to be support for more then one error
> arriving, in which case they were concatenated.  What is happening with
> that?

That still works with respect to libpq's internally-generated errors,
which is as far as I know the only case that the concatenation was
actually useful for.

> Shouldn't the position be available as a separate field, so client
> programs can do their own highlighting or whatnot?

Yes, it is.  The question here is what the backwards-compatible
PQerrorMessage() call should produce.  Do you think position should
get left out of that?  My thought was that the "terse" form should
carry everything that is likely to fit on one line, and position
would usually fit on the same line with "syntax error".  Also, an app
that is using PQerrorMessage() rather than constructing its own
error message from the individual fields is likely not gonna do anything
as helpful as highlighting ...

> One more thing: It has always annoyed me that PQerrorMessage() returns the
> text with a trailing newline.  Since we now redefined newlines to be
> paragraph breaks, should this be changed (in a backward-compatible
> fashion)?

The backwards-compatible part *is* that PQerrorMessage() returns text
with a trailing newline.  If you fetch the individual fields, they don't
have trailing newlines.

			regards, tom lane