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

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?


---------------------------(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

Reply via email to