Re: PQputCopyData dont signal error - Mailing list pgsql-hackers

From David Johnston
Subject Re: PQputCopyData dont signal error
Date
Msg-id 1396132368914-5797912.post@n5.nabble.com
Whole thread Raw
In response to Re: PQputCopyData dont signal error  (steve k <steven.c.kohler@nasa.gov>)
Responses Re: PQputCopyData dont signal error  (steve k <steven.c.kohler@nasa.gov>)
List 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.



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: [COMMITTERS] pgsql: Revert "Secure Unix-domain sockets of "make check" temporary clu
Next
From: Bruce Momjian
Date:
Subject: Re: psql \d+ and oid display