Chris,
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
>
