In order to insert binary data into these columns in the database, the official way to do this is to use an INSERT statement with backslash escaped non-viewable characters. This is done in the form
INSERT INTO mytable (bindata) VALUES(E'\000\\blablahascii'::bytea)
The E prefix is used to indicate that this is an escaped string. In 9.x, if you include the E, you'll get random 'invalid byte sequence for encoding "UTF8": 0x00' errors. If you remove the E, your SQL statements will not be compatible w/ pre-9.x databases that do expect the E prefix.

You can work around this, and keep your code compatible w/ all versions of Postgresql by using hex strings passed into the decode function like so
INSERT INTO mytable (bindata) VALUES ( DECODE('00FFAABBDEADBEEF','HEX') )

You can also use parameterized queries to do the insert by using an STL string (which can contain binary data) using the libpqxx library, but this isn't documented very well
   C.prepare("MyInsert", "INSERT INTO mytable (bindata) VALUES ($1::bytea)")
("bytea", pqxx::prepare::treat_binary);
  const string bin_data("x \0 \x01 \x02 \xff y", 11);
  T.prepared("MyInsert")(bin_data).exec();
It's probably a tossup as to which is more efficient because you'd have to convert your binary array into an STL string with this technique.

The other thing that bit me was Postgresql 9.x changes the default select output representation of BYTEA fields to "hex" (looks like a hex string prefixed with \x, e.g. '\xDEADBEEF') instead of the old "escape" format (same format as the way you insert it). The 3.1 version of the libpqxx apparently doesn't support the "hex" format, so if you read blobs back into binarystrings, they'll be corrupted. You can work around this by editing your postgresql.conf file and setting the bytea_output flag to "escape".