From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Tatsuo Ishii <ishii(at)postgresql(dot)org>, andrew(at)dunslane(dot)net, laurenz(dot)albe(at)wien(dot)gv(dot)at, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: invalidly encoded strings |
Date: | 2007-09-11 16:15:21 |
Message-ID: | 1189527321.5924.109.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-09-11 16:20:24 | Re: What is happening on buildfarm member dugong |
Previous Message | Tom Lane | 2007-09-11 16:08:53 | Re: What is happening on buildfarm member dugong |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2007-09-11 16:46:16 | prevent invalidly encoded input |
Previous Message | Teodor Sigaev | 2007-09-11 16:01:40 | pgsql: Remove QueryOperand->istrue flag, it was used only in cover |