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 по дате отправления:

Предыдущее
От: Ludovico Romano
Дата:
Сообщение: converting MSAccess to PG with ConvertToPostgreSQL.mdb script of Seva Software
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: LIKE erratic? or unseen DB corruption?