Hi Alvaro, Thanks for the prompt response. PGLoader looks like an awesome project and I especially liked this part:
/"Handling PostgreSQL errors Some data will get rejected by PostgreSQL, even after being carefully prepared by the transformation functions you can attach to pgloader. Then pgloader parses the PostgreSQL CONTEXT error message that contains the line number in the batch of where the error did happen. It's then easy enough to *resend the all the rows from the batch that are located before the error, skip and log as rejected the faulty row, and continue*, handling eventual next errors the same way. /" I didn't see anything in the documentation about binary files and that is unfortunately the only thing I have for input currently. They used binary files because that was the fastest way to write the data for each of the frames in the sim without falling out of realtime. We're trying to bring some parts of this project more up to date with the ultimate goal of being able to write directly to the database itself without falling out of realtime and developing a dashboard for researchers to monitor during experiments and simulation runs. Thanks again for the suggestion and I'll definitely keep PGLoader in mind as things unfold here on this project. Best Regards, Steve K. -- View this message in context: http://postgresql.1045698.n5.nabble.com/PQputCopyData-dont-signal-error-tp4302340p5798038.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
