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.