Kern Sibbald <kern@xxxxxxxxxxx> writes: > Bacula sets the database encoding to SQL_ASCII, because although > Bacula "supports" UTF-8 character encoding, it cannot enforce it. Okay ... > CREATE DATABASE bacula ENCODING 'SQL_ASCII'; > > However, with PostgreSQL 8.4, the above command is ignored because the default > table copied is not template0. ... so copy template0. I think you probably want to force C locale (lc_ctype/lc_collate) as well, which was not possible for an individual database before 8.4. So on the whole I think 8.4 ought to be more amenable to what you want than prior versions were. No, it is not exactly the same as prior versions were, but that's the price of progress. > 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. You misread it. We are not talking about eliminating SQL_ASCII --- as you say, that's useful. What is deprecated is trying to use SQL_ASCII with a non-C locale, which is dangerous, and always has been. If you've been putting non-UTF8 data into a database that could be running under a UTF8-dependent locale, I'm surprised you haven't noticed problems already. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
