From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: char() datatype looses strings of all spaces |
Date: | 2003-08-17 05:37:26 |
Message-ID: | 3F3F1496.1020409@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2003-08-17 05:40:30 | Re: Question with hashed IN |
Previous Message | Tom Lane | 2003-08-17 05:34:48 | Re: char() datatype looses strings of all spaces |