From: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
---|---|
To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, dbahena(at)tpv(dot)com(dot)mx |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | AW: regular expressions troubles with char cols |
Date: | 2000-07-05 09:07:56 |
Message-ID: | 219F68D65015D011A8E000006F8590C605BA59B4@sdexcsrv1.f000.d0188.sd.spardat.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> dbahena(at)tpv(dot)com(dot)mx writes:
> > ventasge2000=# create table t1 (c1 char(10),c2 varchar(10));
> > CREATE
> > ventasge2000=# insert into t1 values('XXX666','XXX666');
> > INSERT 182218 1
> > ventasge2000=# select * from t1 where c1 ~ '666$';
> > c1 | c2
> > ----+----
> > (0 rows)
> > ventasge2000=# select * from t1 where c2 ~ '666$';
> > c1 | c2
> > ------------+--------
> > XXX666 | XXX666
> > (1 row)
>
> > Doesn't regular expressions(in particular the $ metachar)
> work properly
> > with char columns????
>
> I see no bug there --- you've forgotten about the trailing spaces in
> the char(10) column. Try c1 ~ '666 *$' if you want to match against a
> variable amount of padding in a char(N) column.
No, imho char(n) is defined to return trailing blanks but be insensitive to
the actual amount of trailing spaces. Thus I do see that this behavior can
be interpreted as a bug here.
In char(n) speak 'ab' = 'ab ' is supposed to be true.
Imho a change from char(6) to char(8) should only require more storage
space in a client program, but be otherwise transparent,
which it currently is not.
Imho a similar problem is that char_length does not return the count to
the last non space character, which imho also is a bug.
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2000-07-05 09:10:27 | Re: [HACKERS] Re: Revised Copyright: is this more palatable?? |
Previous Message | Ron Chmara | 2000-07-05 09:02:36 | Re: Article on MySQL vs. Postgres |