Re: PQputCopyEnd doesn't adhere to its API contract - Mailing list pgsql-hackers

From David G Johnston
Subject Re: PQputCopyEnd doesn't adhere to its API contract
Date
Msg-id CAKFQuwZwNiCv9R=ki-Xd2doa2nh+1tGKYVu-v3_LLaUBJ-tADg@mail.gmail.com
Whole thread Raw
In response to Re: PQputCopyEnd doesn't adhere to its API contract  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Mon, Sep 8, 2014 at 6:19 PM, David Johnston <[hidden email]> wrote:
On Mon, Sep 8, 2014 at 11:45 AM, Robert Haas [via PostgreSQL] <[hidden email]> wrote:
On Thu, Sep 4, 2014 at 6:38 PM, David Johnston
<[hidden email]> wrote:

> One of the trade-offs I mentioned...its more style than anything but
> removing the parenthetical (if there is not error in the command) and
> writing it more directly seemed preferable in an overview such as this.
>
> Better:  The function will either throw an error or return a PGresult
> object[...]

Nope.  This is not C++, nor is it the backend.  It will not throw anything.


​The current sentence reads:
"​The response to this (if there is no error in the command) will be a PGresult object bearing a status code of PGRES_COPY_OUT or PGRES_COPY_IN (depending on the specified copy direction)."

Maybe this is taken for granted by others, and thus can be excluded here, but I'm trying to specify what happens if there is an error in the command...  Apparently one does not get back a PGresult object...

Would simply saying: "A successful response to this will be a PGresult object..." be accurate (enough)?


​Apparently, NULL is the correct answer.  Cannot that just be assumed to be the case or does saying that a failure scenario here returns NULL (or something other than pqResult object) impart useful knowledge?
Dave



View this message in context: Re: PQputCopyEnd doesn't adhere to its API contract
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.

pgsql-hackers by date:

Previous
From: David G Johnston
Date:
Subject: Re: PQputCopyEnd doesn't adhere to its API contract
Next
From: Amit Kapila
Date:
Subject: Re: Scaling shared buffer eviction