On Mon, Oct 10, 2005 at 10:27:27AM -0400, Tom Lane wrote:
> No, SQL_ASCII represents the complete absence of any encoding
> knowledge. With this database setting, changing client_encoding is a
> complete no-op. Postgres will just absorb and re-emit strings exactly
> as they were supplied originally, no matter what client_encoding is.
The documents remain pretty confusing about this, assuming I still
understand the current state of affairs (always a dangerous
assumption). The chart in
<http://developer.postgresql.org/docs/postgres/multibyte.html>, for
instance, says "SQL_ASCII" supports "ASCII". I'm not sure what to do
about this (I've noticed it before, and run into the same quandary).
One possibility is to add something like this immediately below the
chart in the page above:
---snip---
NOTE: SQL_ASCII _does not_ enforce a 7 bit restriction on insertions.
SQL_ASCII does not represent a positive claim that the database knows
all the characters to be 7 bit characters. It represents instead the
complete absence of any encoding knowledge. Inserting high-bit
characters into a database using the SQL_ASCII character set may have
unpredictable results.
---snip---
--
Andrew Sullivan | ajs@crankycanuck.ca
I remember when computers were frustrating because they *did* exactly what
you told them to. That actually seems sort of quaint now.
--J.D. Baldwin