Re: Like vs '=' bug with indexing
От | Hannu Krosing |
---|---|
Тема | Re: Like vs '=' bug with indexing |
Дата | |
Msg-id | 3A7D2058.17373FFD@tm.ee обсуждение исходный текст |
Ответ на | Re: Like vs '=' bug with indexing (m w <mttf2000@yahoo.com>) |
Ответы |
Re: Like vs '=' bug with indexing
Re: Like vs '=' bug with indexing |
Список | pgsql-hackers |
Tom Lane wrote: > > m w <mttf2000@yahoo.com> writes: > > I think this exposes a bug in postgres where either > > index or table scans (I'm not sure which just yet) > > treat a zero differently than a non-zero in a varchar. > > Embedded zeroes aren't supported in char/varchar/text fields, > and cannot be supported in a portable fashion, since these datatypes > rely on functions like strcoll() that don't allow embedded nulls in > strings. 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()) ? > 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 ? > It doesn't seem real practical for us to examine the output of every > C-coded function to make sure it produces a valid value of the datatype. > Illegal returned values are a fault of the function, and ensuing > misbehaviors are still its fault ... Should we not examine "the _possible_ outputs of every C-coded function to make sure it produces a valid value of the datatype" ;) For me producing an invalid data for a datatype seems very much like a bug and it _should_ be reported. ------------- Hannu
В списке pgsql-hackers по дате отправления: