Tom Lane wrote:
If I have locale set to C, I can do this:
regression=# create database u8 encoding 'utf8';
CREATE DATABASE
regression=# create database l1 encoding 'latin1' template u8;
CREATE DATABASE
Had I had any actual utf8 data in u8, l1 would now contain
encoding-corrupt information. Given that we've tried to
clamp down on encoding violations in recent releases, I wonder
why this case is still allowed.
(In non-C locales, this will typically fail because the two
different encodings can't both match the locale. But I don't
believe it's our policy to enforce encoding validity only for
non-C locales.)
We should presumably let the encoding be changed when cloning
from template0, and probably it's reasonable to trust the user
if either source or destination DB encoding is SQL_ASCII.
In other cases I'm thinking it should fail.
Really? You want to forbid selecting an encoding when the source is
template1, which is the default, and template1 is not SQL_ASCII? So the
following sequence woiuld be illegal:
initdb -E latin1
createdb -E utf8
I think we have a bit more thinking to do on this - I don't have a
reasonable solution immediately in my head.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
