Re: invalidly encoded strings
От | Jeff Davis |
---|---|
Тема | Re: invalidly encoded strings |
Дата | |
Msg-id | 1189527321.5924.109.camel@jdavis обсуждение исходный текст |
Ответ на | Re: invalidly encoded strings (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: invalidly encoded strings
|
Список | pgsql-hackers |
On Mon, 2007-09-10 at 23:20 -0400, Tom Lane wrote: > The reason we have a problem here is that we've been choosing > convenience over safety in encoding-related issues. I wonder if we must > stoop to having a "strict_encoding_checks" GUC variable to satisfy > everyone. That would be satisfactory to me. However, I'm sure some will cringe at a MySQL-like configurable integrity option. Might it be better as an initdb-time option? I can't think why anyone would want to change it later. > It might work the way you are expecting if the database uses SQL_ASCII > encoding and C locale --- and I'd be fine with allowing convert() only > when the database encoding is SQL_ASCII. I prefer this option. It's consistent with the docs, which say: "The SQL_ASCII setting behaves considerably differently from the other settings," and also "One way to use multiple encodings safely is to set the locale to C or POSIX during initdb, thus disabling any real locale awareness." Regards,Jeff Davis
В списке pgsql-hackers по дате отправления: