Re: Like vs '=' bug with indexing
От | Tom Lane |
---|---|
Тема | Re: Like vs '=' bug with indexing |
Дата | |
Msg-id | 6654.981312327@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Like vs '=' bug with indexing (Hannu Krosing <hannu@tm.ee>) |
Список | pgsql-hackers |
Hannu Krosing <hannu@tm.ee> writes: > Is there no simple (i.e. cheap) way to disallow \0 alltogether for > these types then ? > perhaps just strip them out in textin() (or is it text_in()) ? They *are* stripped out in textin(), by virtue of the fact that textin expects to see a null-terminated input string. >> It wouldn't surprise me too much if there are inconsistent >> behaviors between indexscans and seqscans for such invalid data. > should'nt they both use the _same_ strcoll() and friends ? Irrelevant; the issue is that the various comparison operators may produce inconsistent results given invalid input. For instance texteq() short-circuits to a FALSE result if the lengths of the inputs are different, which means that 'ab\0' = 'ab' will produce false, even though a strcoll-based comparison will claim they are equal. I don't think that means that texteq() is wrong to check the lengths first. > Should we not examine "the _possible_ outputs of every C-coded function > to make sure it produces a valid value of the datatype" ;) Go for it. Possibly chr() should reject chr(0) ... regards, tom lane
В списке pgsql-hackers по дате отправления: