Marc Cuypers <m.cuypers@xxxxxxx> writes: > Error: > ERROR: encoding LATIN9 does not match server's locale nl_BE.utf8 > SQL state: XX000 > Detail: The server's LC_CTYPE setting requires encoding UTF8. > > Can i only use nl_BE and UTF-8 now? > Why can't i use LATIN9 anymore? > Is bacula 8.3 stricter in this respect to 7.4? 8.3 is stricter about checking that the configuration makes sense. But even under 7.4 you would have had problems, you just wouldn't have been forewarned so soon. You would still only be able to use nl_BE.utf8 collation but you would have been allowed to tell the server your data was encoded with latin9. So the collation results would have been nonsensical. Ie, comparisons like < and > would have given incorrect results. If this database is still under development and your schedule allows one option might be use 8.4dev from CVS. It should be released sometime in the next 3-6 months and will allow you to have a different encoding and locale for each database. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
