Thread: 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