I'm using psql mydb # copy attachments FROM '/opt/tmp/clientdata/sql-data-p/attachments.dat' with NULL as 'NULL';
to load the database back in. The psql command runs on the same box as the DB server. If I had my way, I'd store the binary somewhere and keep a reference to it in the database. Having binary data (images, PDFs, etc.) in the database never made much sense to me. But this is a client's DB. They used to have an application written in something called "Progress 4GL" and now ported all that to use PostgreSQL with what ever front end (I have no idea). I believe they are using the new app just like the old app, so unfortunately, I can't just go and change the underlying database structure. Hope this helps to clarify the issue. > On Oct 27, 2014, at 15:57 , David G Johnston <david.g.johns...@gmail.com> > wrote: > > PostgreSQL does not like NUL (0x00) in the data that it is importing - I > don't believe it matters what encoding you are using. That said it would > help to clarify exactly how you are running the copy command - specifically > client or server. > > I haven't ever personally encountered this situation but any chance you can > base64 encode on output and then import that way into the new database on a > staging table then decode and manipulate the staged data before storing it > into the permanent table? > > David J. > > > > > -- > View this message in context: > http://postgresql.1045698.n5.nabble.com/Importing-binary-data-tp5824488p5824490.html > Sent from the PostgreSQL - general mailing list archive at Nabble.com. > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
