Tom Lane wrote:
> 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
