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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match