From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Adrian Klaver <aklaver(at)comcast(dot)net>, pgsql-hackers(at)postgresql(dot)org, Kern Sibbald <kern(at)sibbald(dot)com> |
Subject: | Re: Catastrophic changes to PostgreSQL 8.4 |
Date: | 2009-12-03 15:51:03 |
Message-ID: | 9537.1259855463@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)edu> writes:
>> CREATE DATABASE bacula ENCODING 'SQL_ASCII';
>> ERROR: new encoding (SQL_ASCII) is incompatible with the encoding of the
>> template database (UTF8)
>> HINT: Use the same encoding as in the template database, or use template0 as
>> template.
> Actually I'm kind of surprised at this. I don't see a reason not to
> allow converting a template to SQL_ASCII from any encoding given that
> we're going to allow them to put random bytes into the database
> afterwards. Why not let them start with random bytes?
Hm, that's a good point, although we should still enforce that the new
database's LC_xxx settings be C/POSIX if it's SQL_ASCII. My guess is
that the initdb environment had some non-C locale, so this example would
have failed the next error check anyway.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2009-12-03 15:54:34 | Re: [Bacula-users] Catastrophic changes to PostgreSQL 8.4 |
Previous Message | Scott Marlowe | 2009-12-03 15:49:46 | Re: numeric cast oddity |
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2009-12-03 15:54:34 | Re: [Bacula-users] Catastrophic changes to PostgreSQL 8.4 |
Previous Message | Tom Lane | 2009-12-03 15:46:54 | Re: Catastrophic changes to PostgreSQL 8.4 |