ascii() is defined as ascii(text). As of 7.4, bpchar->text conversion strips trailing blanks, so what ascii() sees is a zero-length string.
That makes sense -- I was wondering where the blanks got stripped.
Given that trailing blanks are insignificant in bpchar, I'm not sure I'd call this a bug. If we decide it is, we could work around it by creating an ascii(bpchar) entry ... but what's the argument that says insignificant trailing blanks must map to the same thing as significant blanks?
No strong argument -- I only found it because of the behavior change, and a bug in my own database creation script from a couple of years ago. I had a field defined CHAR, when what I really wanted was "char". With whatever was current at the time, ascii() gave me a 32 for the single blank value. Now it doesn't. I should just fix my script.
Joe
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
