On Fri, 2002-07-12 at 08:50, Tom Lane wrote:
Scott Royston [EMAIL PROTECTED] writes:
[ various examples of comparing char and varchar ]
I see no bug here. For the CHAR datatype, trailing spaces are defined
to be insignificant. For VARCHAR and TEXT, trailing spaces are
significant. If
I guess the strangest part was that both a.foo = 'S' and b.foo = 'S' but
not a.foo=b.foo; (a.foo is varchar(5) , b.foo is char(5) )
I guess that tha 'S' that b.foo gets compared to is converted to 'S'
before comparison but when comparing varchar(5) and char(5) they are
both compared
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
If the conversion where varchar(5) -- char(5) then
they would compare equal.
I am not sure, since, if the varchar stored 'S ' then the comparison
to a char 'S' should probably still fail,
There is no comparison of varchar to char:
Has anyone studied how other DBMSs handle CHAR vs VARCHAR? Judging
from the number of questions we get on this point, I have to wonder
if we are not out of step with the way other systems do it.
Well, I already gave the Informix example, that compares them as equal.
(they obviously coerce
On Fri, 12 Jul 2002, Tom Lane wrote:
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
If the conversion where varchar(5) -- char(5) then
they would compare equal.
I am not sure, since, if the varchar stored 'S ' then the comparison
to a char 'S' should probably still fail,
There
: Hannu Krosing; Scott Royston; [EMAIL PROTECTED]
Subject: Re: [HACKERS] string cast/compare broken?
Has anyone studied how other DBMSs handle CHAR vs VARCHAR? Judging
from the number of questions we get on this point, I have to wonder
if we are not out of step with the way other systems do
On Fri, Jul 12, 2002 at 03:48:59PM +0200, Zeugswetter Andreas SB SD wrote:
Imho the advantages of an automatic coercion would outweigh the few
corner cases where the behavior would not be intuitive to
everybody.
How then would one get the correct behaviour from char()?
A
--
Andrew
Mac OS X:
postgres% psql --version
psql (PostgreSQL) 7.2.1
contains support for: multibyte
LEDEV=# create table test1 (foo varchar(5));
CREATE
LEDEV=# create table test2 (foo char(5));
CREATE
LEDEV=# insert into test2 (foo) values ('S');
INSERT 3724249 1
LEDEV=# insert into test1 (foo) values
Scott Royston [EMAIL PROTECTED] writes:
[ various examples of comparing char and varchar ]
I see no bug here. For the CHAR datatype, trailing spaces are defined
to be insignificant. For VARCHAR and TEXT, trailing spaces are
significant. If you want to compare a CHAR value to a VARCHAR or
