Re: Some quick notes about extending libpq for new - Mailing list pgsql-interfaces

From Peter Eisentraut
Subject Re: Some quick notes about extending libpq for new
Date
Msg-id Pine.LNX.4.44.0306161602130.2751-100000@peter.localdomain
Whole thread Raw
In response to Some quick notes about extending libpq for new protocol  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Some quick notes about extending libpq for new protocol
List pgsql-interfaces
Tom Lane writes:

> * Access to individual fields of an error/notice result; also some setting to
> determine how verbose PQerrorMessage is
>
>     char *PQerrorField(conn, char fieldcode)
>     char *PQresultErrorField(const PGresult *res, char fieldcode)
>
> fieldcode is as per the protocol spec.  NULL is returned if no such field in
> current result (this includes case where current result isn't an error).

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?

>     PQsetErrorVerbosity(conn, PQERRORS_TERSE/DEFAULT/VERBOSE)
>
> TERSE: single-line error (severity, primary text, and position only)

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

> DEFAULT: above plus any detail, hint, or context fields (backwards compatible)
> VERBOSE: all available data

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)?

-- 
Peter Eisentraut   peter_e@gmx.net



pgsql-interfaces by date:

Previous
From: Tom Lane
Date:
Subject: Re: ECPG CVS version problems
Next
From: Tom Lane
Date:
Subject: Re: Some quick notes about extending libpq for new protocol