David,
The code I posted is what I started/finished with. As I tried to figure
things out I kept adding PQgetResult, PQresultStatus and
PQresultErrorMessage calls and writing the results to the log file. By the
time I was done it was so messy that I stripped all that messaging/logging
back out and made sure it ran with good data and moved on to something else
because I couldn't waste any more time on it and figured I'd look it over
again if the insert with multiple values clauses was a bust too (which
thankfully it wasn't).
When I got the multiple values clause insert replacements going and compared
processing times and error handling I dumped all the old debugging version
stuff because that's not the kind of thing you commit to version control.
In the end I didn't think it mattered because I wasn't going to use any of
it since I had no way to know if bad data actually didn't get written by
virtue of its being bad data. And no return code ever indicated anything
was awry.
I'd love to see an actual working example where an executing C++ program was
able to in fact determine that copy data containing bad data that was sent
by the C++ program was rejected by the server and subsequently the C++
program was able to raise/log/notify specifically which block of data failed
and then log information about it. However, all I ever got was
PGRES_COMMAND_OK whether or not the data that was sent was rejected as
containing bad data or not. Effectively these were silent failures.
Sorry I can't provide more information but I do appreciate your time. If
you can't get any further with it I understand and don't expect another
reply.
Regards,
Steve K.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/PQputCopyData-dont-signal-error-tp4302340p5798104.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.