2009/12/3 Kern Sibbald <kern@xxxxxxxxxxx>: > Hello, > > Thanks for all the answers; I am a bit overwhelmed by the number, so I am > going to try to answer everyone in one email. > > The first thing to understand is that it is *impossible* to know what the > encoding is on the client machine (FD -- or File daemon). On say a > Unix/Linux system, the user could create filenames with non-UTF-8 then switch > to UTF-8, or restore files that were tarred on Windows or on Mac, or simply > copy a Mac directory. Finally, using system calls to create a file, you can > put *any* character into a filename. > > So, rather than trying to figure everything out (impossible, I think) and > rather than failing to backup files, Bacula gets the "raw" filename from the > OS and stores it on the Volume then puts it in the database. We treat the > filename as if it is UTF-8 for display purposes, but in all other cases, what > we want is for the filename to go into the database and come back out > unchanged. > > On MySQL we use BLOBS. On PostgreSQL, we TEXT and set the encoding to > SQL_ASCII so that PostgreSQL will not attempt to do any translation. This > works well, and I hope that PostgreSQL will continue to support letting > Bacula insert text characters in the database with no character encoding > checks in the future. Hello just use bytea datatype instead text. http://www.postgresql.org/docs/8.4/interactive/datatype-binary.html it is exactly what you wont. Regards Pavel Stehule -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
