Re: invalidly encoded strings

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