Thread: char() datatype looses strings of all spaces

I stumbled across this behavior today and it seems strange if not a bug:

-- this seems wrong
vsconf=# create table foo (f1 char(1));
CREATE TABLE
vsconf=# insert into foo values(' ');
INSERT 9002011 1
vsconf=# select ascii(f1) from foo; ascii
-------     0
(1 row)

-- this is what I'd expect
vsconf=# create table foo2 (f1 varchar(1));
CREATE TABLE
vsconf=# insert into foo2 values(' ');
INSERT 9002015 1
vsconf=# select ascii(f1) from foo2; ascii
-------    32
(1 row)

-- this seems wrong
vsconf=# create table foo4 (f1 char(5));
CREATE TABLE
vsconf=# insert into foo4 values('     ');
INSERT 9002022 1
vsconf=# select ascii(f1) from foo4; ascii
-------     0
(1 row)

I looked for a few minutes at bpcharin(), but could not see exactly why 
this is happening. Am I missing something wrt the char() data type, or 
is this a bug?

Joe

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

Joe Conway <mail@joeconway.com> writes:
> I stumbled across this behavior today and it seems strange if not a bug:

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.

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?
        regards, tom lane

On Sat, 16 Aug 2003, Joe Conway wrote:

> I stumbled across this behavior today and it seems strange if not a bug:
>
> -- this seems wrong
> vsconf=# create table foo (f1 char(1));
> CREATE TABLE
> vsconf=# insert into foo values(' ');
> INSERT 9002011 1
> vsconf=# select ascii(f1) from foo;
>   ascii
> -------
>       0
> (1 row)

I think the reason for this is that ascii is actually
defined ascii(text) and the conversion from char(n)
to text now drops the trailing spaces.