Hello,
I am the project manager of Bacula. One of the database backends that Bacula
uses is PostgreSQL.
This email is to notify you that a change you made to setting database
character codes has created havoc with certain unfortunate Bacula users.
Bacula sets the database encoding to SQL_ASCII, because although
Bacula "supports" UTF-8 character encoding, it cannot enforce it. Certain
operating systems such as Unix, Linux and MacOS can have filenames that are
not in UTF-8 format. Since Bacula stores filenames in PostgreSQL tables, we
use SQL_ASCII.
We set SQL_ASCII by default when creating the database via the command
recommended in recent versions of PostgreSQL (e.g. 8.1), with:
CREATE DATABASE bacula ENCODING 'SQL_ASCII';
However, with PostgreSQL 8.4, the above command is ignored because the default
table copied is not template0. This means that some Bacula users who have
created PostgreSQL databases with version 8.4, typically find them created
with SQL_UTF8 format, which results in serious errors when doing backups for
certain machines.
Apparently, for PostgreSQL 8.4, one must specify:
CREATE DATABASE bacula ENCODING 'SQL_ASCII' TEMPLATE=template0;
Rather than making this incompatible modification, it would have been
advisable to make the default equivalent to the above. Of course I imagine
that there are lots of reasons why that could not be programmed as such.
I also notice the following comment in your 8.4 documentation:
"PostgreSQL will allow superusers to create databases with SQL_ASCII
encoding even when LC_CTYPE is not C or POSIX. As noted above, SQL_ASCII does
not enforce that the data stored in the database has any particular encoding,
and so this choice poses risks of locale-dependent misbehavior. Using this
combination of settings is deprecated and may someday be forbidden
altogether."
If you do eliminate SQL_ASCII at some point, it would be a real pity and
create a lot of inconvience for your users.
Regards,
Kern
