Kern Sibbald k...@sibbald.com writes:
Concerning the future: I am still a bit concerning about the mention in the
document of possible future changes concerning SQL_ASCII and LC_CTYPE not C
or POSIX (Using this combination of settings is deprecated and may someday
be forbidden altogether.
On Thursday 03 December 2009 16:42:58 Adrian Klaver wrote:
On Wednesday 02 December 2009 11:33:38 pm Kern Sibbald wrote:
( BTW, one way to handle incorrectly encoded filenames and paths might
be to have a `bytea' field that's generally null to store such mangled
file names. Personally
Hello,
Thanks for your response.
On Thursday 03 December 2009 16:46:54 Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
As others have said; BYTEA is probably the best datatype for you to
use. The encoding of BYTEA literals is a bit of a fiddle and may need
some changes, but it's
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
2009/12/3 Kern Sibbald k...@sibbald.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
Kern Sibbald wrote:
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
Craig Ringer wrote:
Kern Sibbald wrote:
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
Craig Ringer wrote:
While true in theory, in practice it's pretty unusual to have filenames
encoded with an encoding other than the system LC_CTYPE on a modern
UNIX/Linux/BSD machine.
It depends. In western Europe, where iso-8859-1[5] and utf8 are evenly used,
it's not unusual at all.
Craig Ringer wrote:
Kern Sibbald wrote:
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
On Thu, Dec 03, 2009 at 08:33:38AM +0100, Kern Sibbald wrote:
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
Kern Sibbald wrote:
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.
We aim to please, and overwhelm. :-)
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB
On Thu, Dec 3, 2009 at 8:33 AM, Craig Ringer
cr...@postnewspapers.com.au wrote:
While true in theory, in practice it's pretty unusual to have filenames
encoded with an encoding other than the system LC_CTYPE on a modern
UNIX/Linux/BSD machine.
I'd _very_ much prefer to have Bacula back my
On Wednesday 02 December 2009 11:33:38 pm Kern Sibbald wrote:
( BTW, one way to handle incorrectly encoded filenames and paths might
be to have a `bytea' field that's generally null to store such mangled
file names. Personally though I'd favour just rejecting them. )
We set SQL_ASCII
Sam Mason s...@samason.me.uk writes:
As others have said; BYTEA is probably the best datatype for you to
use. The encoding of BYTEA literals is a bit of a fiddle and may need
some changes, but it's going to be much more faithful to your needs of
treating the filename as an opaque blob of
Frank Sweetser wrote:
Unless, of course, you're at a good sized school with lots of
international students, and have fileservers holding filenames created
on desktops running in Chinese, Turkish, Russian, and other locales.
What I struggle with here is why they're not using ru_RU.UTF-8,
On Thu, 3 Dec 2009 12:22:50 +0100 (CET)
Kern Sibbald k...@sibbald.com wrote:
Yes, that is my experience too. I understand Craig's comments,
but I would much prefer that Bacula just backup and restore and
leave the checking of filename consistencies to other programs.
At least for the moment,
On Thu, Dec 03, 2009 at 10:46:54AM -0500, Tom Lane wrote:
Sam Mason s...@samason.me.uk writes:
As others have said; BYTEA is probably the best datatype for you to
use. The encoding of BYTEA literals is a bit of a fiddle and may need
some changes, but it's going to be much more faithful to
On 12/03/2009 10:54 AM, Craig Ringer wrote:
Frank Sweetser wrote:
Unless, of course, you're at a good sized school with lots of
international students, and have fileservers holding filenames created
on desktops running in Chinese, Turkish, Russian, and other locales.
What I struggle with
Hi Avi
Please have a look at this link, this is how to install Bacula with MYSQL
database with Hebrew support
Eitan
On Thu, Dec 3, 2009 at 12:35 PM, Avi Rozen avi.ro...@gmail.com wrote:
Craig Ringer wrote:
Kern Sibbald wrote:
Hello,
Thanks for all the answers; I am a bit
On 12/3/2009 3:33 AM, Craig Ringer wrote:
Kern Sibbald wrote:
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
Craig Ringer wrote:
Frank Sweetser wrote:
Unless, of course, you're at a good sized school with lots of
international students, and have fileservers holding filenames created
on desktops running in Chinese, Turkish, Russian, and other locales.
What I struggle with here is why they're
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
Kern Sibbald k...@sibbald.com 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
On Wednesday 02 December 2009 5:18:52 am Kern Sibbald wrote:
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
On 2/12/2009 9:18 PM, Kern Sibbald wrote:
Hello,
I am the project manager of Bacula. One of the database backends that Bacula
uses is PostgreSQL.
As a Bacula user (though I'm not on the Bacula lists), first - thanks
for all your work. It's practically eliminated all human intervention
from
Craig Ringer cr...@postnewspapers.com.au writes:
It's a pity that attempting to specify an encoding other than the safe
one when using a non-template0 database doesn't cause the CREATE
DATABASE command to fail with an error.
Huh?
regression=# create database foo lc_ctype = 'en_US.utf8'
On 3/12/2009 11:03 AM, Tom Lane wrote:
Craig Ringercr...@postnewspapers.com.au writes:
It's a pity that attempting to specify an encoding other than the safe
one when using a non-template0 database doesn't cause the CREATE
DATABASE command to fail with an error.
Huh?
regression=# create
On 3/12/2009 11:09 AM, Jerome Alet wrote:
On Thu, Dec 03, 2009 at 10:54:07AM +0800, Craig Ringer wrote:
Anyway, it'd be nice if Bacula would convert file names to utf-8 at the
file daemon, using the encoding of the client, for storage in a utf-8
database.
+1 for me.
this is the way to go.
* Craig Ringer (cr...@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
On Thu, Dec 03, 2009 at 10:54:07AM +0800, Craig Ringer wrote:
Anyway, it'd be nice if Bacula would convert file names to utf-8 at the
file daemon, using the encoding of the client, for storage in a utf-8
database.
+1 for me.
this is the way to go.
I understand people with an existing backup
Hi!
On Thu, Dec 3, 2009 at 10:39 PM, Jerome Alet jerome.a...@univ-nc.nc wrote:
On Thu, Dec 03, 2009 at 10:54:07AM +0800, Craig Ringer wrote:
Anyway, it'd be nice if Bacula would convert file names to utf-8 at the
file daemon, using the encoding of the client, for storage in a utf-8
database.
Stephen Frost wrote:
* Craig Ringer (cr...@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
32 matches
Mail list logo
