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.
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 |