sql_ascii
Why do we have SQL_ASCII?
I could understand it if we only could store 7-bit strings there. But
SQL_ASCII lets you store 8-bit values. Should I understand SQL_ASCII
simply as 8-bit strings of unknown charset?
In the first database I created I used it to store latin1 strings, and
that was a mistake. I'm sure others have made the same mistake.
I've looked at the code and as far as I can tell postgres converts ascii
to utf-8 using a function in conv.c called pg_ascii2mic() which simply
strips off the upper bit. Still when I have a SQL_ASCII database and a
table with strings like "Bj�rklund" (notice the � which is not 7-bit
ascii) and change client encoding to UTF-8 I still get 8-bit values out
(yes, it's stange, that's why I ask).
I know how to fix my database, no problem. I'm just interested in why I
get 8-bit values out when I've set the client encoding to utf-8. I guess
my problem is the same as above, I don't know what sql_ascii really is.
I don't need to know these things to fix the small problems in psql (which
I'll do in the weekend), but I figured that it's just as good to
understand all of it an anyway.
--
/Dennis
Dennis Bjï¿œrklund writes:
Why do we have SQL_ASCII?
It gives a simple default behavior for people who don't want to deal with
character set issues.
I could understand it if we only could store 7-bit strings there. But
SQL_ASCII lets you store 8-bit values. Should I understand SQL_ASCII
simply as 8-bit strings of unknown charset?
Something like that. On the client side you could also understand it as
whatever the server is using, as long as that's single-byte. On the
server side it's 7-bit clean and 8-bit sometimes-clean. It's not pretty.
--
Peter Eisentraut peter_e@gmx.net