On Thursday 03 December 2009 17:35:33 Bill Moran wrote:
> All the comments below are just a bit overzealous and just a bit overly
> dramatic.
>
> Keep in mind that the only thing that is happening is that the PostgreSQL
> server is putting restrictions on _when_ you can create a SQL_ASCII
> database. They're not proposing to remove SQL_ASCII support, they're
> simply making the system complain more loudly if such creation doesn't
> make sense in the context of the OS environment.
Yes, I had misunderstood. I now understand what additional constraints may be
placed on SQL_ASCII, and have ensured that in postgres 8.4 and later they
will be met.
>
> As a result, I recommend the following changes:
> 1) Document the importance of PostgreSQL database encoding with some
> tricks and suggestions for what to do if creating the database isn't
> working as expected.
I've done that in the create_postgresql_database.in script, and we will add
more documentation to the manual.
> 2) Ensure the schema creation script _always_ creates SQL_ASCII (I
> believe Dan has already done this?)
Yes, Dan did fix the basic problem by creating the DB from template0 rather
than template1. I've addeded additional protection as recommended by Tom
Lane, so the problem should not come back unless a user explicitly creates an
SQL_UTF8 database.
> 3) Add a check in the PG driver code for Bacula that checks to see that
> the database is SQL_ASCII on startup and exits with a descriptive
> error message if it is not.
This has been in for some time (added 15 Feb 2009), but it was not in version
2.4.4 where this problem showed up earlier this week :-(
>
> Switching to BYTEA fields does not meet the needs of the Bacula project.
> Bacula's needs are one of the oddball cases where SQL_ASCII actually
> makes sense, and using SQL_ASCII is _NOT_ a hack, it's the correct
> way to do things.
Agreed, and confirmed by Tom Lane, so we are sticking with SQL_ASCII.
Thanks for the comments,
Kern
>
> In response to Jacek Konieczny <jajcus AT jajcus DOT net>:
> > On Thu, Dec 03, 2009 at 08:33:38AM +0100, Kern Sibbald wrote:
> > > 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.
> >
> > Then decide if bacula treats filenames as opaque identifiers or text
> > (set of defined human-readable characters). Whatever you decide, TEXT
> > with SQL_ASCII encoding is not the right choice.
> >
> > If we decide filenames are just opaque identifiers, then BYTEA (isn't
> > that the same what the "BLOBS" in MySQL), not TEXT should be used. TEXT
> > is a string of characters. BYTEA is a string of bytes. Bytes with no
> > specified encoding are not characters.
> >
> > Advantages:
> > - any filename used in the system may be stored in bacula database
> > - on restore it will be restored under the exact same name
> > Disadvantages:
> > - database text operations may not work on such data
> > - when file is restored on a system with different encoding its name
> > will not be what a user expects. Or event restore would not be
> > possible there (such string of bytes may be invalid for filename on
> > such system)
> >
> > If we decide filenames are text, then use TEXT fields with proper
> > encoding.
> >
> > Advantages:
> > - all text operations will work well on the filenames in the database
> > - whatever encoding target system uses the filenames will be right
> > after restore
> > Disadvantages:
> > - no way to know how to store filename if the system encoding is not
> > known
> > - if filename is badly encoded it cannot be stored in the database
> > as-is (though it may be mangled so the data can still be restored)
> >
> > Using SQL_TEXT is just a hack. Hack may be an option, but it should not
> > be the important design decision and requirement.
> >
> > Greets,
> > Jacek
> >
> > -------------------------------------------------------------------------
> >----- Join us December 9, 2009 for the Red Hat Virtual Experience,
> > a free event focused on virtualization and cloud computing.
> > Attend in-depth sessions from your desk. Your couch. Anywhere.
> > http://p.sf.net/sfu/redhat-sfdev2dev
> > _______________________________________________
> > Bacula-devel mailing list
> > Bacula-devel AT lists.sourceforge DOT net
> > https://lists.sourceforge.net/lists/listinfo/bacula-devel
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
