From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Why do we let CREATE DATABASE reassign encoding? |
Date: | 2009-04-23 18:50:47 |
Message-ID: | 49F0B887.1000209@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-04-23 18:52:57 | Re: Why do we let CREATE DATABASE reassign encoding? |
Previous Message | Tom Lane | 2009-04-23 18:47:27 | Re: PL compilations ignores LDFLAGS |