Peter Eisentraut [EMAIL PROTECTED] 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
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
