Re: Like vs '=' bug with indexing - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Like vs '=' bug with indexing
Date
Msg-id 3A7D2058.17373FFD@tm.ee
Whole thread Raw
In response to Re: Like vs '=' bug with indexing  (m w <mttf2000@yahoo.com>)
Responses Re: Like vs '=' bug with indexing  (m w <mttf2000@yahoo.com>)
Re: Like vs '=' bug with indexing  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: TODO list: Allow Java server-side programming
Next
From: Mario Weilguni
Date:
Subject: Implementing an operator in C?