From: | Frank Miles <fpm(at)u(dot)washington(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: LIKE erratic? or unseen DB corruption? |
Date: | 2001-05-21 16:52:32 |
Message-ID: | Pine.A41.4.33.0105210946110.15760-100000@mead4.u.washington.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, 21 May 2001, Tom Lane wrote:
> Frank Miles <fpm(at)u(dot)washington(dot)edu> writes:
> > A direct query gets appropriate rows of data:
> > dbname=# select * from partdef where shpname = 'IDC16W';
> > ...while the very same query (substituting LIKE for the '=' sign) gets nothing!?
>
> Hm. Does EXPLAIN show the same kind of plan (index or seq scan) for
> both queries? If not, does forcing the plan choice via ENABLE_xxxSCAN
> make a difference? Do you have locale support turned on, and if so
> what locale are you using?
>
> regards, tom lane
Seq scan for '=' and for 'LIKE'; no locale support enabling. As Len
Morgan suggested, it appears to be a matter of LIKE being sensitive to
trailing spaces, and '=' NOT being sensitive to them. The field data type
is char(16) {not stated in my original message}.
Is "LIKE" deprecated for testing when a trailing '%' isn't used (e.g. wx%yz)?
Regexp is certainly a possible alternative, especially given the seq scan.
Though I have to say it seems weird that '=' matches, and 'LIKE' doesn't.
Thanks for your help!
-frank
From | Date | Subject | |
---|---|---|---|
Next Message | Denis A. Doroshenko | 2001-05-21 16:53:22 | Re: psql shell problem |
Previous Message | Zak McGregor | 2001-05-21 16:50:10 | Re: Queries across multiple databases (was: SELECT from a table in another database). |