Albe Laurenz wrote:
There's one thing that strikes me as weird in your implementation:
pgsql=# select chr(0);
ERROR: character 0x00 of encoding "SQL_ASCII" has no equivalent in
"UTF8"
0x00 is a valid UNICODE code point and also a valid UTF-8 character!
It's not my code that rejects this. I'm passing the resultant string to
the pg_verify_mbstr(...) function and it is rejecting a null. I could
change that, of course, but if other parts of the system found it
reasonable to reject null, why should chr() be different?
This was also one of the questions I asked upthread. Does changing the
behavior of chr() break people's reasonable expectations?
mark
---------------------------(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
