Re: PQputCopyData dont signal error

From: David Johnston <polobo(at)yahoo(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: PQputCopyData dont signal error
Date: 2014-03-29 22:32:48
Message-ID: 1396132368914-5797912.post@n5.nabble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

steve k wrote
> I realize this is an old thread, but seems to be the only discussion I can
> find on this topic "I have a problem with PQputCopyData function. It
> doesn't signal some error. "
>
> I am using from within a c++ program:
> PQexec(m_pConn, "COPY... ...FROM stdin"),
>
> followed by PQputCopyData(m_pConn, ssQuery.str().c_str(),
> ssQuery.str().length()),
>
> finished with PQputCopyEnd(m_pConn, NULL).

This may be over simplified but...

To summarize here the PQexec needs a matching PQgetResult. The PQputCopyEnd
only "closes" the preceding PQputCopyData. The server is not compelled to
process the copy data until the client says that no more data is coming.
Once the PQputCopyEnd has returned for practical purposes you back to the
generic command handling API and need to proceed as you would for any other
command - including being prepared to wait for long-running commands and
handle errors.

The request in this thread is for some means for the client to send partial
data and if the server has chosen to process that data (or maybe the client
can compel it to start...) AND has encountered an error then the client can
simply abort the rest of the copy and return an error. The current API
return values deal with the results of the actual call just performed and
not with any pre-existing state on the server. Tom's suggestion is to add a
polling method to query the current server state for those who care to
expend the overhead instead of imposing that overhead on all callers.

The C API seems strange to me, a non-C programmer, but at a cursory glance
it is at least internally consistent and does provide lots of flexibility
(especially for sync/async options) at the cost of complexity and having to
make sure that you code in the appropriate PQgetResult checks or risk
ignoring errors and reporting success incorrectly.

David J.

--
View this message in context: http://postgresql.1045698.n5.nabble.com/PQputCopyData-dont-signal-error-tp4302340p5797912.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2014-03-29 22:33:39 Re: psql \d+ and oid display
Previous Message Noah Misch 2014-03-29 22:29:34 Re: pgsql: Revert "Secure Unix-domain sockets of "make check" temporary clu