> Tatsuo Ishii wrote: > > > <SNIP>. I think we need to continute design discussion, probably > > targetting for 8.4, not 8.3. > > The discussion came about because Andrew - Supernews noticed that chr() > returns invalid utf8, and we're trying to fix all the bugs with invalid > utf8 in the system. Something needs to be done, even if we just check > the result of the current chr() implementation and throw an error on > invalid results. But do we want to make this minor change for 8.3 and > then change it again for 8.4?
My opinion was in the snipped part by you in the previous mail -- Limiting chr() to ASCII range -- Tatsuo Ishii SRA OSS, Inc. Japan > Here's an example of the current problem. It's an 8.2.3 database with > utf8.en_US encoding > > > mark=# create table testutf8 (t text); > CREATE TABLE > mark=# insert into testutf8 (t) (select chr(gs) from > generate_series(0,255) as gs); > INSERT 0 256 > mark=# \copy testutf8 to testutf8.data > mark=# truncate testutf8; > TRUNCATE TABLE > mark=# \copy testutf8 from testutf8.data > ERROR: invalid byte sequence for encoding "UTF8": 0x80 > HINT: This error can also happen if the byte sequence does not match > the encoding expected by the server, which is controlled by > "client_encoding". > CONTEXT: COPY testutf8, line 129 > > > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
