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@xxxxxxxxxxxxxxx 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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
