Re: Why do we let CREATE DATABASE reassign encoding?
От | Andrew Dunstan |
---|---|
Тема | Re: Why do we let CREATE DATABASE reassign encoding? |
Дата | |
Msg-id | 49F0B887.1000209@dunslane.net обсуждение исходный текст |
Ответ на | Why do we let CREATE DATABASE reassign encoding? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Why do we let CREATE DATABASE reassign encoding?
|
Список | 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
В списке pgsql-hackers по дате отправления: