All the comments below are just a bit overzealous and just a bit overly dramatic.
Keep in mind that the only thing that is happening is that the PostgreSQL server is putting restrictions on _when_ you can create a SQL_ASCII database. They're not proposing to remove SQL_ASCII support, they're simply making the system complain more loudly if such creation doesn't make sense in the context of the OS environment. As a result, I recommend the following changes: 1) Document the importance of PostgreSQL database encoding with some tricks and suggestions for what to do if creating the database isn't working as expected. 2) Ensure the schema creation script _always_ creates SQL_ASCII (I believe Dan has already done this?) 3) Add a check in the PG driver code for Bacula that checks to see that the database is SQL_ASCII on startup and exits with a descriptive error message if it is not. Switching to BYTEA fields does not meet the needs of the Bacula project. Bacula's needs are one of the oddball cases where SQL_ASCII actually makes sense, and using SQL_ASCII is _NOT_ a hack, it's the correct way to do things. In response to Jacek Konieczny <jaj...@jajcus.net>: > On Thu, Dec 03, 2009 at 08:33:38AM +0100, Kern Sibbald wrote: > > 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. > > Then decide if bacula treats filenames as opaque identifiers or text > (set of defined human-readable characters). Whatever you decide, TEXT > with SQL_ASCII encoding is not the right choice. > > If we decide filenames are just opaque identifiers, then BYTEA (isn't > that the same what the "BLOBS" in MySQL), not TEXT should be used. TEXT > is a string of characters. BYTEA is a string of bytes. Bytes with no > specified encoding are not characters. > > Advantages: > - any filename used in the system may be stored in bacula database > - on restore it will be restored under the exact same name > Disadvantages: > - database text operations may not work on such data > - when file is restored on a system with different encoding its name > will not be what a user expects. Or event restore would not be > possible there (such string of bytes may be invalid for filename on > such system) > > If we decide filenames are text, then use TEXT fields with proper > encoding. > > Advantages: > - all text operations will work well on the filenames in the database > - whatever encoding target system uses the filenames will be right > after restore > Disadvantages: > - no way to know how to store filename if the system encoding is not > known > - if filename is badly encoded it cannot be stored in the database > as-is (though it may be mangled so the data can still be restored) > > Using SQL_TEXT is just a hack. Hack may be an option, but it should not > be the important design decision and requirement. > > Greets, > Jacek > > ------------------------------------------------------------------------------ > Join us December 9, 2009 for the Red Hat Virtual Experience, > a free event focused on virtualization and cloud computing. > Attend in-depth sessions from your desk. Your couch. Anywhere. > http://p.sf.net/sfu/redhat-sfdev2dev > _______________________________________________ > Bacula-devel mailing list > Bacula-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-devel -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmo...@collaborativefusion.com Phone: 412-422-3463x4023 **************************************************************** IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. **************************************************************** ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
