Re: Catastrophic changes to PostgreSQL 8.4

2009/12/3 Kern Sibbald <kern(at)sibbald(dot)com>:
> 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