Обсуждение: lower/upper functions and strings in searches

I am obviuously doing some newbie trick, and I ordinarily would spend time browing the archives, but the
archives.postgresql.orgsite seems to be absurdly slow. 

This is 7.3.3 on a linux box.

I have a bunch of data with state, city, county and country names. When our application does a search for an exact
match:

select * from gx_geotowns where l_state = 'NM'; I get back a lot of rows of cities in New Mexico, as expected.

If I try:

select * from gx_geotowns where upper(l_state) = upper('nm');

I get back:
---------+-----------+----------+------------+------+------
(0 rows)

I've used other databases in which a similar statement worked as exepected:
select * from clientswhere upper(client_name) = upper("Some client or otheR");

And it finds the row(s) in question ...

I just know I'm overlooking some real obvious thing but for some reason this eludes me. I could see if the search was
veryslow (the function returns type "text" and the indexed columns are of type CHAR(). 

If someone could offer help I would appreciate it,

Thanks,

Greg Williamson
DBA GlobeXplorer LLC

On Thu, 14 Aug 2003, Gregory S. Williamson wrote:

> I am obviuously doing some newbie trick, and I ordinarily would spend time browing the archives, but the
archives.postgresql.orgsite seems to be absurdly slow.
 
>
> This is 7.3.3 on a linux box.
>
> I have a bunch of data with state, city, county and country names. When our application does a search for an exact
match:
>
> select * from gx_geotowns where l_state = 'NM';
>   I get back a lot of rows of cities in New Mexico, as expected.
>
> If I try:
>
> select * from gx_geotowns where upper(l_state) = upper('nm');

You say the column is of type CHAR(), but CHAR(2) or something else?

For 7.3 and earlier, you're going to get a text comparison which means
that trailing spaces are significant (it's effectively no pad in text vs
pad space in char).

Gregory,

> I just know I'm overlooking some real obvious thing but for some reason this
eludes me. I could see if the search was very slow (the function returns type
"text" and the indexed columns are of type CHAR().

Char(what?)  ?

if it's, say CHAR(4) that could be your problem;
'NM'::undefined == 'NM  '::CHAR
but
'NM'::TEXT != 'NM  '::CHAR
so casting everything to the desired type should fix the problem.

and why are you using CHAR, anyway?


--
-Josh BerkusAglio Database SolutionsSan Francisco