Re: char() datatype looses strings of all spaces

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