Stephen Frost wrote:
> * Craig Ringer (craig@postnewspapers.com.au) wrote:
>> ... so it's defaulting to SQL_ASCII, but actually supports utf-8 if your
>> systems are all in a utf-8 locale. Assuming there's some way for the
>> filed to find out the encoding of the director's database, it probably
>> wouldn't be too tricky to convert non-matching file names to the
>> director's encoding in the fd (when the director's encoding isn't
>> SQL_ASCII, of course).
>
> I'm not sure which piece of bacula connects to PostgreSQL, but whatever
> it is, it could just send a 'set client_encoding' to the PG backend and
> all the conversion will be done by PG.
The director is responsible for managing all the metadata, and it's the
component that connects to Pg.
If the fd sent the system charset along with the bundle of filenames etc
that it sends to the director, then I don't see why the director
couldn't `SET client_encoding' appropriately before inserting data from
that fd, then `RESET client_encoding' once the batch insert was done.
The only downside is that if even one file has invalidly encoded data,
the whole batch insert fails and is rolled back. For that reason, I'd
personally prefer that the fd handle conversion so that it can exclude
such files (with a loud complaint in the error log) or munge the file
name into something that _can_ be stored.
Come to think of it, if the fd and database are both on a utf-8
encoding, the fd should *still* validate the utf-8 filenames it reads.
There's no guarantee that just because the system thinks the filename
should be utf-8, it's actually valid utf-8, and it'd be good to catch
this at the fd rather than messing up the batch insert by the director,
thus making it much safer than it presently is to use Bacula with a
utf-8 database.
--
Craig Ringer
