From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Randall Lucas <rlucas(at)tercent(dot)net> |
Cc: | "Nicolas JOUANIN" <n(dot)jouanin(at)regie-france(dot)com>, pgsql-sql(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: TR: Like and = |
Date: | 2003-06-23 17:35:39 |
Message-ID: | 2063.1056389739@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-sql |
Randall Lucas <rlucas(at)tercent(dot)net> writes:
> The LIKE operator takes a pattern, and since your pattern did not
> specify a wildcard at the end, it didn't exactly match the padded
> string.
> This behavior does seem kind of confusing;
Yeah. As of CVS tip, the system is actually going out of its way to
cause this to happen: if we deleted the separate ~~ operator for bpchar,
then the automatic rtrim() that now happens when converting bpchar to
text would cause the extra spaces to go away, and the LIKE would work
as Nicolas is expecting. On the other hand, this would probably create
some backwards-compatibility issues, since existing uses of LIKE with
bpchar operands are no doubt using patterns that expect the spaces to be
there. Any opinions whether we should change it or not?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dann Corbit | 2003-06-23 18:55:34 | Re: Two weeks to feature freeze |
Previous Message | Bruce Momjian | 2003-06-23 17:34:27 | Re: dblink_ora - a first shot on Oracle ... |
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Bertheau | 2003-06-23 18:16:55 | Re: multi-table unique index |
Previous Message | Michael A Nachbaur | 2003-06-23 17:32:56 | Re: multi-table unique index |