Re: LIKE erratic? or unseen DB corruption?
От | Frank Miles |
---|---|
Тема | Re: LIKE erratic? or unseen DB corruption? |
Дата | |
Msg-id | Pine.A41.4.33.0105210946110.15760-100000@mead4.u.washington.edu обсуждение исходный текст |
Ответ на | Re: LIKE erratic? or unseen DB corruption? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
On Mon, 21 May 2001, Tom Lane wrote: > Frank Miles <fpm@u.washington.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
В списке pgsql-general по дате отправления: