Hi Tom, Thanks for that. It's somewhat clearer now. I went ahead and rebuilt the DB with no problems so I guess that whatever data was in the DB converted OK. Regards Iain > "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 4: Don't 'kill -9' the postmaster
