"Iain" <[EMAIL PROTECTED]> writes:
> I read the info written by Tasuo, but I have to admit that the whole
> encoding thing is still full of mystery for me. For example, if the database
> has a SQL_ASCII encoding and you enter japanese text, what encoding is used?
> Does it depend on the client used to enter it?
I'm not an expert on this stuff, but my understanding is that setting
the encoding to SQL_ASCII disables all encoding-conversion logic ---
whatever bytes the client sends are what get stored. So if you want
to change the setting from SQL_ASCII to something else, you'd better be
sure that everything every client has stored is compatible with the new
encoding specification.
> My understanding is that the DB
> doesn't ensure that data makes sense in the set encoding,
When you select a real encoding spec (not SQL_ASCII) then the DB does
check that entered strings are valid in that encoding. Also it will
attempt to do encoding conversion, if clients specify they are using
a client_encoding that is different from the database encoding (and
is not SQL_ASCII).
Hope that helps --- if not, try Tatsuo ...
regards, tom lane
---------------------------(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
