SQL_ASCII means that the data could be anything. It could be Latin1, UTF-8, Latin9, whatever the code inserting data sends to the server. In general the server accepts anything as SQL_ASCII. In general this doesn't cause any problems as long as all the clients have a common understanding on what the real encoding of the data is. However if you set CLIENT_ENCODING then the server does assume that the data is really 7bit ascii.
In the jdbc driver we only support US-ASCII data if the character set is SQL_ASCII since we use the CLIENT_ENCODING setting of UTF8 to have the server perform the necessary conversion for us since java needs unicode strings. And if you store anything other than US-ASCII data in a SQL_ASCII database the server will return invalid UTF-8 data to the client.
thanks, --Barry
Christopher Kings-Lynne wrote:
Hi,
In phpPgAdmin, we automatically set the HTML page encoding to and encoding that allows us to properly display the encoding of the current postgresql database. I have a small problem with SQL_ASCII. Theoretically (and what we currently do), we should set page encoding to US-ASCII. However, Postgres seems to allow unlauts and all sorts of extra 8 bit data in ASCII databases, so what encoding should I use. Is ISO-8859-1 a better choice? Is SQL_ASCII basically equivalent to the LATIN1 encoding?
My other question is we play around with bytea fields to escape nulls and chars < 32 and stuff so that when someone browses the table, they get '\000<unknown>\000...', etc. However, are the other field types for which we have to do this? Can you put nulls and stuff in text/varchar/char fields? What about other fields?
Thanks,
Chris
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
