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. -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers